pcim_iomap_table() and pcim_iomap_regions() have been deprecated.
Replace them with pcim_iomap_region().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250404121911.85277-6-phasta@kernel.org
pcim_iomap_table() and pcim_iomap_regions() have been deprecated.
Replace them with pcim_iomap_region().
Additionally, the "name" parameter of pcim_iomap_region() should reflect
the driver's, not the hardware's, name. Pass the correct parameter.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250404121911.85277-5-phasta@kernel.org
pcim_iomap_table() and pcim_iomap_regions() have been deprecated.
Replace them with pcim_iomap_region().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250404121911.85277-4-phasta@kernel.org
pcim_iomap_table() and pcim_iomap_regions() have been deprecated.
Replace them with pcim_iomap_region().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250404121911.85277-3-phasta@kernel.org
Add aliases for the MMC devices so that after the system starts up,
they will all have fixed device numbers.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Link: https://lore.kernel.org/r/20250324125215.160616-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Follow most others rk356x based boards, and u-boot only use mmc0/1
as mmc boot targets, so aliase sdhci as mmc0.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
[demo-board only used internally by Rockchip, so changing the alias order
does not affect public users]
Link: https://lore.kernel.org/r/20241221104920.4193034-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
While looking through the vendor U-Boot code Heiko spotted that a SoC
GPIO is connected to the ethernet phy's reset pin. Add the respective
reset-gpios property with pinmuxing for the GPIO to the phy node.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/49f66206fccc714a8745b9ac35247615ad5cc369.1742331667.git.ukleinek@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
With the binding header now providing the SCMI_SRST_H_TRNG_NS constant,
switch back to it from the temporary numeric value.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Until now the emmc worked when booting because the bootrom set up the
pin config correctly to load the initial bootloader from it.
So when the kernel started it "just" reused this setup but never made
sure it was actually correct.
This then breaks when the system is started via some other means, like
downloading the initial bootloader via the bootrom usb download.
With actual emmc pin-config added, barebox is able to access the eMMC
even when booted via USB.
Fixes: 9da1c0327d ("arm64: dts: rockchip: Add basic support for QNAP TS-433")
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
[refined commit message to explain that we're currently just running
on bootom-goodwill]
Link: https://lore.kernel.org/r/20250319113138.125192-2-uwe@kleine-koenig.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The differences in the vendor-approved CPU and GPU OPPs for the standard
Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J variant [2]
come from the latter, presumably, supporting an extended temperature range
that's usually associated with industrial applications, despite the two SoC
variant datasheets specifying the same upper limit for the allowed ambient
temperature for both variants. However, the lower temperature limit is
specified much lower for the RK3588J variant. [1][2]
To be on the safe side and to ensure maximum longevity of the RK3588J SoCs,
only the CPU and GPU OPPs that are declared by the vendor to be always safe
for this SoC variant may be provided. As explained by the vendor [3] and
according to the RK3588J datasheet, [2] higher-frequency/higher-voltage
CPU and GPU OPPs can be used as well, but at the risk of reducing the SoC
lifetime expectancy. Presumably, using the higher OPPs may be safe only
when not enjoying the assumed extended temperature range that the RK3588J,
as an SoC variant targeted specifically at higher-temperature, industrial
applications, is made (or binned) for.
Anyone able to keep their RK3588J-based board outside the above-presumed
extended temperature range at all times, and willing to take the associated
risk of possibly reducing the SoC lifetime expectancy, is free to apply
a DT overlay that adds the higher CPU and GPU OPPs.
With all this and the downstream RK3588(J) DT definitions [4][5] in mind,
let's delete the RK3588J CPU and GPU OPPs that are not considered belonging
to the normal operation mode for this SoC variant. To quote the RK3588J
datasheet [2], "normal mode means the chipset works under safety voltage
and frequency; for the industrial environment, highly recommend to keep in
normal mode, the lifetime is reasonably guaranteed", while "overdrive mode
brings higher frequency, and the voltage will increase accordingly; under
the overdrive mode for a long time, the chipset may shorten the lifetime,
especially in high-temperature condition".
To sum the RK3588J datasheet [2] and the vendor-provided DTs up, [4][5]
the maximum allowed CPU core, GPU and NPU frequencies are as follows:
IP core | Normal mode | Overdrive mode
------------+-------------+----------------
Cortex-A55 | 1,296 MHz | 1,704 MHz
Cortex-A76 | 1,608 MHz | 2,016 MHz
GPU | 700 MHz | 850 MHz
NPU | 800 MHz | 950 MHz
Unfortunately, when it comes to the actual voltages for the RK3588J CPU and
GPU OPPs, there's a discrepancy between the RK3588J datasheet [2] and the
downstream kernel code. [4][5] The RK3588J datasheet states that "the max.
working voltage of CPU/GPU/NPU is 0.75 V under the normal mode", while the
downstream kernel code actually allows voltage ranges that go up to 0.95 V,
which is still within the voltage range allowed by the datasheet. However,
the RK3588J datasheet also tells us to "strictly refer to the software
configuration of SDK and the hardware reference design", so let's embrace
the voltage ranges provided by the downstream kernel code, which also
prevents the undesirable theoretical outcome of ending up with no usable
OPPs on a particular board, as a result of the board's voltage regulator(s)
being unable to deliver the exact voltages, for whatever reason.
The above-described voltage ranges for the RK3588J CPU OPPs remain taken
from the downstream kernel code [4][5] by picking the highest, worst-bin
values, which ensure that all RK3588J bins will work reliably. Yes, with
some power inevitably wasted as unnecessarily generated heat, but the
reliability is paramount, together with the longevity. This deficiency
may be revisited separately at some point in the future.
The provided RK3588J CPU OPPs follow the slightly debatable "provide only
the highest-frequency OPP from the same-voltage group" approach that's been
established earlier, [6] as a result of the "same-voltage, lower-frequency"
OPPs being considered inefficient from the IPA governor's standpoint, which
may also be revisited separately at some point in the future.
[1] https://wiki.friendlyelec.com/wiki/images/e/ee/Rockchip_RK3588_Datasheet_V1.6-20231016.pdf
[2] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403201054_Rockchip-RK3588J_C22364189.pdf
[3] https://lore.kernel.org/linux-rockchip/e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de/T/#u
[4] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
[5] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
[6] https://lore.kernel.org/all/20240229-rk-dts-additions-v3-5-6afe8473a631@gmail.com/
Fixes: 667885a686 ("arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j")
Fixes: a7b2070505 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j")
Cc: stable@vger.kernel.org
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Alexey Charkov <alchark@gmail.com>
Helped-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/eeec0d30d79b019d111b3f0aa2456e69896b2caa.1742813866.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3588 thermal sensor driver only receives interrupts when a
higher-temperature threshold is crossed; it cannot notify when the
sensor cools back off. As a result, the driver must poll for temperature
changes to detect when the conditions for a thermal trip are no longer
met. However, it only does so if the DT enables polling.
Before this patch, the RK1 DT did not enable polling, causing the fan to
continue running at the speed corresponding to the highest temperature
reached.
Follow suit with similar RK3588 boards by setting a polling-delay of
1000ms, enabling the driver to detect when the sensor cools back off,
allowing the fan speed to decrease as appropriate.
Fixes: 7c8ec5e6b9 ("arm64: dts: rockchip: Enable automatic fan control on Turing RK1")
Cc: stable@kernel.org # v6.13+
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250329165017.3885-1-CFSworks@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
__VA_OPT__ is a macro that is useful when some arguments can be present
or not to entirely skip some part of a definition. Unfortunately, it
is a too recent addition that some of the still supported old GCC
versions do not know about, and is anyway not part of C11 that is the
version used in the kernel.
Find a trick to remove this macro, typically '__VA_ARGS__ + 0' is a
workaround used in netlink.h which works very well here, as we either
expect:
- 0
- A positive value
- No value, which means the field should be 0.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202503181330.YcDXGy7F-lkp@intel.com/
Fixes: 7ce0d16d58 ("mtd: spinand: Add an optional frequency to read from cache macros")
Cc: stable@vger.kernel.org
Tested-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
In r852_ready(), the dev get from r852_get_dev() need to be checked.
An unstable device should not be ready. A proper implementation can
be found in r852_read_byte(). Add a status check and return 0 when it is
unstable.
Fixes: 50a487e771 ("mtd: rawnand: Pass a nand_chip object to chip->dev_ready()")
Cc: stable@vger.kernel.org # v4.20+
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
In INFTL_findwriteunit(), the return value of inftl_read_oob()
need to be checked. A proper implementation can be
found in INFTL_deleteblock(). The status will be set as
SECTOR_IGNORE to break from the while-loop correctly
if the inftl_read_oob() fails.
Fixes: 8593fbc68b ("[MTD] Rework the out of band handling completely")
Cc: stable@vger.kernel.org # v2.6+
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
If CONFIG_SPI_QPIC_SNAND=m, but CONFIG_MTD_NAND_QCOM=n:
ERROR: modpost: "qcom_nandc_unalloc" [drivers/spi/spi-qpic-snand.ko] undefined!
...
Fix this by dropping the explicit test for a built-in
CONFIG_SPI_QPIC_SNAND completely. Kbuild handles multiple and mixed
obj-y/obj-m rules for the same object file fine.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202503280759.XhwLcV7m-lkp@intel.com/
Fixes: 7304d19090 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Some drivers as well as the character device and sysfs code check
whether the line actually is in output mode before allowing the user to
set a value.
However, GPIO value setters now return integer values and can indicate
failures. This allows us to move these checks into the core code.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250311-gpio-set-check-output-v1-1-d971bca9e6fa@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
When the Tegra186 GPIO controller is probed through ACPI matching,
the driver emits two error messages during probing:
"tegra186-gpio NVDA0508:00: invalid resource (null)"
"tegra186-gpio NVDA0508:00: invalid resource (null)"
Fix this by getting resource first and then do the ioremap.
Fixes: 2606e7c9f5 ("gpio: tegra186: Add ACPI support")
Cc: stable@vger.kernel.org
Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
Link: https://lore.kernel.org/r/20250327032349.78809-1-kanie@linux.alibaba.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Build fails with:
error: multiple unsequenced modifications to 'sbuf32'
[-Werror,-Wunsequenced]
264 | le32_to_cpup(sbuf32++),
| ^
265 | le32_to_cpup(sbuf32++),
| ~~
With that move the increment of the sbuf32 pointer to the end of the
loop, instead of inside the array list initializer, where the
order/sequence of the sbuf32 pointer modifications is not defined.
Fixes: 58523a25cb ("drm/format-helper: Optimize 32-to-24-bpp conversion")
Fixes: 3f31a017dd ("drm/format-helper: Optimize 32-to-16-bpp conversion")
Fixes: 65931bbc51 ("drm/format-helper: Optimize 32-to-8-bpp conversion")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250402104430.142398-2-matthew.auld@intel.com
Andy Shevchenko <andriy.shevchenko@linux.intel.com> says:
A simple refactoring of the GPIO ACPI library parts to get an impressive
~8% code shrink on x86_64 and ~2% on x86_32. Also reduces a C code a bit.
add/remove: 0/2 grow/shrink: 0/5 up/down: 0/-1221 (-1221)
Function old new delta
acpi_gpio_property_lookup 425 414 -11
acpi_find_gpio.__UNIQUE_ID_ddebug478 56 - -56
acpi_dev_gpio_irq_wake_get_by.__UNIQUE_ID_ddebug480 56 - -56
acpi_find_gpio 354 216 -138
acpi_get_gpiod_by_index 462 307 -155
__acpi_find_gpio 877 638 -239
acpi_dev_gpio_irq_wake_get_by 695 129 -566
Total: Before=15375, After=14154, chg -7.94%
Link: https://lore.kernel.org/r/20250403160034.2680485-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
__acpi_find_gpio() calls two functions depending on the supplied con_id
and possibility to fallback to _CRS lookup. Those functions have the same
pieces of code that can be done only in one place. Do it so.
This gives an impressive shrink of the generated code for x86_64:
add/remove: 0/2 grow/shrink: 0/4 up/down: 0/-1204 (-1204)
Function old new delta
acpi_find_gpio.__UNIQUE_ID_ddebug478 56 - -56
acpi_dev_gpio_irq_wake_get_by.__UNIQUE_ID_ddebug480 56 - -56
acpi_find_gpio 354 216 -138
acpi_get_gpiod_by_index 456 307 -149
__acpi_find_gpio 877 638 -239
acpi_dev_gpio_irq_wake_get_by 695 129 -566
Total: Before=15358, After=14154, chg -7.84%
Acked-by: Mika Westerberg <westeri@kernel.org>
Link: https://lore.kernel.org/r/20250403160034.2680485-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Some of the contents of struct acpi_gpio_lookup repeats what we have
in the struct acpi_gpio_params. Reuse the latter in the former.
Acked-by: Mika Westerberg <westeri@kernel.org>
Link: https://lore.kernel.org/r/20250403160034.2680485-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Rename par to params for better readability in acpi_get_driver_gpio_data().
No functional changes intended.
Requested-by: Bartosz Golaszewski <brgl@bgdev.pl>
Acked-by: Mika Westerberg <westeri@kernel.org>
Link: https://lore.kernel.org/r/20250403160034.2680485-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The line_index member in the struct acpi_gpio_params replicates
what is covered in the ACPI GpioIo() or GpioInt() resource.
The value there is limited to 16-bit one, so we don't really need
to have a full 32-bit storage for it. Together with followed
boolean the structure will be smaller.
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-3 (-3)
Function old new delta
acpi_gpio_property_lookup 417 414 -3
Total: Before=15361, After=15358, chg -0.02%
`pahole` difference before and after:
- /* size: 12, cachelines: 1, members: 3 */
- /* padding: 3 */
+ /* size: 8, cachelines: 1, members: 3 */
+ /* padding: 1 */
Acked-by: Mika Westerberg <westeri@kernel.org>
Link: https://lore.kernel.org/r/20250403160034.2680485-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
In all cases the supplied index is the same as the passed one in
the struct acpi_gpio_lookup. Remove index parameter and reuse one
from the struct acpi_gpio_lookup instead.
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-14 (-14)
Function old new delta
acpi_get_gpiod_by_index 462 456 -6
acpi_gpio_property_lookup 425 417 -8
Total: Before=15375, After=15361, chg -0.09%
Acked-by: Mika Westerberg <westeri@kernel.org>
Link: https://lore.kernel.org/r/20250403160034.2680485-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The struct acpi_gpio_info has two boolean members that are located
not close to each other making two gaps due to alignment requirements.
Group them to improve memory footprint.
`pahole` difference before and after (on 32-bit):
- /* size: 36, cachelines: 1, members: 9 */
- /* sum members: 30, holes: 2, sum holes: 6 */
+ /* size: 32, cachelines: 1, members: 9 */
+ /* sum members: 30, holes: 1, sum holes: 2 */
Acked-by: Mika Westerberg <westeri@kernel.org>
Link: https://lore.kernel.org/r/20250403160034.2680485-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Modules without a description now cause a warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/xen/xenbus/xenbus_probe_frontend.o
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20250328113302.2632353-1-arnd@kernel.org>
The RZ/G2L driver utilises the VSPD to read data from input sources.
The rzg2l_du_kms component lists a restricted subset of the capabilities
of the VSPD which prevents additional formats from being used for
display planes.
The supported display plane formats are mapped in rzg2l_du_vsp_formats[].
Extend the rzg2l_du_format_infos[] table with the corresponding mappings
between the supported DRM formats and the formats exposed by the VSP in
rzg2l_du_vsp_formats, maintaining the same ordering in both tables.
The RPF module on VSPD supports various format conversion and send the
image data to BRS(Blend ROP Sub Unit) for further processing.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Link: https://lore.kernel.org/r/20250330102357.56010-3-biju.das.jz@bp.renesas.com
Add a test to check memblock_set_node() behavior.
And create a corner case in which the memblock.reserved array is doubled
during memblock_set_node(). And finally make sure all regions in
memblock.reserved are with valid node id.
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
CC: Mike Rapoport <rppt@kernel.org>
CC: Yajun Deng <yajun.deng@linux.dev>
Link: https://lore.kernel.org/r/20250318071948.23854-4-richard.weiyang@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Commit 61167ad5fe ("mm: pass nid to reserve_bootmem_region()") introduce
a way to set nid to all reserved region.
But there is a corner case it will leave some region with invalid nid.
When memblock_set_node() doubles the array of memblock.reserved, it may
lead to a new reserved region before current position. The new region
will be left with an invalid node id.
Repeat the process when detecting it.
Fixes: 61167ad5fe ("mm: pass nid to reserve_bootmem_region()")
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
CC: Mike Rapoport <rppt@kernel.org>
CC: Yajun Deng <yajun.deng@linux.dev>
CC: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250318071948.23854-3-richard.weiyang@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
The second parameter of memblock_set_node() is size instead of end.
Since it iterates from lower address to higher address, finally the node
id is correct. But during the process, some of them are wrong.
Pass size instead of end.
Fixes: 61167ad5fe ("mm: pass nid to reserve_bootmem_region()")
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
CC: Mike Rapoport <rppt@kernel.org>
CC: Yajun Deng <yajun.deng@linux.dev>
CC: stable@vger.kernel.org
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20250318071948.23854-2-richard.weiyang@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
We need to access the PMIC during late system shutdown and at that time
we are not allowed to sleep anymore.
To make this case work, and since we can't detect this case in a
non-racy way, switch to using udelay() unconditionally, instead of
usleep_range().
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://lore.kernel.org/r/20250325-acpm-atomic-v3-2-c66aae7df925@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
acpm_dequeue_by_polling() uses a loop counter and assumes that each
iteration of the loop takes 20us. It may take longer, though, because
usleep_range() may sleep a different amount.
Switch to using ktime_get() / ktime_before() to detect the timeout
condition more reliably.
This change also makes the code easier to follow and it allows us to
adjust the sleep if necessary, without having to adjust the loop
counter exit condition.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://lore.kernel.org/r/20250325-acpm-atomic-v3-1-c66aae7df925@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
drivers/media/cec/i2c/tda9950.c: In function 'tda9950_write_range':
drivers/media/cec/i2c/tda9950.c:92:15: error: implicit declaration of function 'i2c_transfer' [-Wimplicit-function-declaration]
92 | ret = i2c_transfer(client->adapter, &msg, 1);
| ^~~~~~~~~~~~
drivers/media/cec/i2c/tda9950.c: In function 'tda9950_probe':
drivers/media/cec/i2c/tda9950.c:391:14: error: implicit declaration of function 'i2c_check_functionality' [-Wimplicit-function-declaration]
391 | if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
| ^~~~~~~~~~~~~~~~~~~~~~~
Fixes: caa6f4a75e ("media: cec: move driver for TDA9950 from drm/i2c")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
In order to get the v4l2_subdev functions you need to select
MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202503151002.HacBN2LO-lkp@intel.com/
Fixes: e49563c3be ("media: i2c: add lt6911uxe hdmi bridge driver")
For now, the Synopsys HDMI HDMI RX Controller is only supported on
Rockchip RK3588 SoCs. Hence add a dependency on ARCH_ROCKCHIP, to
prevent asking the user about this driver when configuring a kernel
without Rockchip SoC support.
Fixes: 7b59b132ad ("media: platform: synopsys: Add support for HDMI input driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Shreeya Patel <shreeya.patel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The new driver fails to build if I2C is disabled:
drivers/media/i2c/lt6911uxe.c:703:1: error: data definition has no type or storage class [-Werror]
703 | module_i2c_driver(lt6911uxe_i2c_driver);
or if I2C is on but V4L2_CCI_I2C is not:
ERROR: modpost: "cci_write" [drivers/media/i2c/lt6911uxe.ko] undefined!
ERROR: modpost: "cci_read" [drivers/media/i2c/lt6911uxe.ko] undefined!
For both by adding a dependency on I2C and selecting V4L2_CCI_I2C, which
follows the common practice for these.
Fixes: e49563c3be ("media: i2c: add lt6911uxe hdmi bridge driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
It's not enough to have a dependency on CONFIG_FB, as that can be in
a loadable module when vivid itself is builtin:
drivers/media/test-drivers/vivid/vivid-osd.o: in function `vivid_fb_init':
vivid-osd.c:(.text+0xdc0): undefined reference to `fb_alloc_cmap'
vivid-osd.c:(.text+0xe26): undefined reference to `register_framebuffer'
Change the dependency to only allow configurations that can be built,
but change the FB to FB_CORE so this is also possible when using
DRM with FB compatibility rather than full fbdev.
Fixes: 20889ddede ("media: vivid: Introduce VIDEO_VIVID_OSD")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
When mounting the same share twice, once with the "linux" mount parameter
(or equivalently "posix") and then once without (or e.g. with "nolinux"),
we were incorrectly reusing the same tree connection for both mounts.
This meant that the first mount of the share on the client, would
cause subsequent mounts of that same share on the same client to
ignore that mount parm ("linux" vs. "nolinux") and incorrectly reuse
the same tcon.
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Fix regression in mounts to e.g. onedrive shares.
Generally, reparse points are processed by the SMB server during the
SMB OPEN request, but there are few reparse points which do not have
OPEN-like meaning for the SMB server and has to be processed by the SMB
client. Those are symlinks and special files (fifo, socket, block, char).
For Linux SMB client, it is required to process also name surrogate reparse
points as they represent another entity on the SMB server system. Linux
client will mark them as separate mount points. Examples of name surrogate
reparse points are NTFS junction points (e.g. created by the "mklink" tool
on Windows servers).
So after processing the name surrogate reparse points, clear the
-EOPNOTSUPP error code returned from the parse_reparse_point() to let SMB
server to process reparse points.
And remove printing misleading error message "unhandled reparse tag:" as
reparse points are handled by SMB server and hence unhandled fact is normal
operation.
Fixes: cad3fc0a4c ("cifs: Throw -EOPNOTSUPP error on unsupported reparse point type from parse_reparse_point()")
Fixes: b587fd1286 ("cifs: Treat unhandled directory name surrogate reparse points as mount directory nodes")
Cc: stable@vger.kernel.org
Reported-by: Junwen Sun <sunjw8888@gmail.com>
Tested-by: Junwen Sun <sunjw8888@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
When we're polling for responses and get a response that corresponds to
another request, we save the RX data in order to drain the RX queue.
If the response for the current request is not found in the request's
iteration of the queue, or if the queue is empty, we must check whether
the RX data was saved by a previous request when it drained the RX queue.
We failed to check for already saved responses when the queue was empty,
and requests could time out. Check saved RX before bailing out on empty
RX queue.
Fixes: a88927b534 ("firmware: add Exynos ACPM protocol driver")
Reported-by: André Draszik <andre.draszik@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
Tested-by: André Draszik <andre.draszik@linaro.org>
Link: https://lore.kernel.org/r/20250324-acpm-drained-rx-queue-v1-1-577774335151@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
