On 8/20/2025 7:34 PM, Dmitry Baryshkov wrote:
> On Wed, Aug 20, 2025 at 05:34:46PM +0800, Xiangxu Yin wrote:
>> Introduce qmp_phy_usbc_type enum and a 'type' field in qmp_phy_cfg to
>> differentiate between USB-only PHYs and USB/DP switchable PHYs.
>>
>> Signed-off-by: Xiangxu Yin
>> ---
>> dri
On 8/20/2025 7:37 PM, Dmitry Baryshkov wrote:
> On Wed, Aug 20, 2025 at 05:34:44PM +0800, Xiangxu Yin wrote:
>> Add device tree binding documentation for the Qualcomm QMP USB3+DP PHY
>> on QCS615 Platform. This PHY supports both USB3 and DP functionality
>> over USB-C, with PHY mode switching cap
On 8/20/2025 6:09 PM, Dmitry Baryshkov wrote:
> On Wed, Aug 20, 2025 at 05:34:44PM +0800, Xiangxu Yin wrote:
>> Add device tree binding documentation for the Qualcomm QMP USB3+DP PHY
>> on QCS615 Platform. This PHY supports both USB3 and DP functionality
>> over USB-C, with PHY mode switching cap
From: Andy Yan
Enable the Mini DisplayPort on this board.
Note that ROCKCHIP_VOP2_EP_DP0 is defined as 10 in dt-binding header,
but it will trigger a dtc warning like "graph node unit address error,
expected "a"" if we use it directly after endpoint, so we use "a"
instead here.
Signed-off-by: An
From: Andy Yan
The DP1 is compliant with the DisplayPort Specification
Version 1.4, and share the USBDP combo PHY1 with USB 3.1
HOST1 controller.
Signed-off-by: Andy Yan
Reviewed-by: Sebastian Reichel
---
(no changes since v1)
.../arm64/boot/dts/rockchip/rk3588-extra.dtsi | 30 +
From: Andy Yan
The DP0 is compliant with the DisplayPort Specification
Version 1.4, and share the USBDP combo PHY0 with USB 3.1
HOST0 controller.
Signed-off-by: Andy Yan
Reviewed-by: Sebastian Reichel
---
(no changes since v1)
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 30 +
From: Andy Yan
The Rockchip RK3588 SoC integrates the Synopsys DesignWare DPTX
controller. And this DPTX controller need share a USBDP PHY with
the USB 3.0 OTG controller during operation.
Signed-off-by: Andy Yan
Reviewed-by: Rob Herring (Arm)
---
(no changes since v2)
Changes in v2:
- Link
From: Andy Yan
RA620 is a DP to HDMI bridge converter from RADXA, which first
found be used on ROCK 5 ITX.
This chip can be used without involving software.
Signed-off-by: Andy Yan
Acked-by: Krzysztof Kozlowski
---
(no changes since v3)
Changes in v3:
- First introduced in this version.
From: Andy Yan
The DW DP TX Controller is compliant with the DisplayPort Specification
Version 1.4 with the following features:
* DisplayPort 1.4a
* Main Link: 1/2/4 lanes
* Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and 8.1Gbps
* AUX channel 1Mbps
* Single Stream Transport(SST)
* Multistream
From: Andy Yan
The HDMI0(Port next to Headphone Jack) is drived by DP1 on rk3588
via RA620(a dp2hdmi converter).
Add related dt nodes to enable it.
Note: ROCKCHIP_VOP2_EP_DP1 is defined as 11 in dt-binding header,
but it will trigger a dtc warning like "graph node unit address
error, expected "
From: Andy Yan
Add an entry for the DW DPTX Controller bridge driver.
Signed-off-by: Andy Yan
Reviewed-by: Dmitry Baryshkov
---
(no changes since v5)
Changes in v5:
- First included in this version.
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAIN
From: Andy Yan
The RA620 is an active DP to HDMI converter chip, basically
no software is involved to drive it.
Add it to simple bridge to make it can be find by the drm bridge chain.
Signed-off-by: Andy Yan
Reviewed-by: Dmitry Baryshkov
---
Changes in v7:
- Fix a typo in subject: s/birdge/
From: Andy Yan
There are two DW DPTX based DisplayPort Controller on rk3588 which
are compliant with the DisplayPort Specification Version 1.4 with
the following features:
* DisplayPort 1.4a
* Main Link: 1/2/4 lanes
* Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and 8.1Gbps
* AUX channel 1Mbps
From: Andy Yan
Add driver extension for Synopsys DesignWare DPTX IP used
on Rockchip RK3588 SoC.
Signed-off-by: Andy Yan
Acked-by: Dmitry Baryshkov
Tested-by: Nicolas Frattaroli
---
(no changes since v4)
Changes in v4:
- Drop unused function
- Add platform_set_drvdata
Changes in v2:
- no
On 22.08.25 06:09, Mika Penttilä wrote:
On 8/21/25 23:06, David Hildenbrand wrote:
All pages were already initialized and set to PageReserved() with a
refcount of 1 by MM init code.
Just to be sure, how is this working with MEMBLOCK_RSRV_NOINIT, where MM is
supposed not to
initialize struct
On 22.08.25 03:59, Damien Le Moal wrote:
On 8/22/25 05:06, David Hildenbrand wrote:
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: Damien Le Moal
Cc: Niklas Cassel
Signed-off-by: David Hildenbrand
---
drivers
Use dev_err_probe() helper as recommended by core driver model in
drivers/base/core.c to handle deferred probe error. Improve code
consistency and debuggability using standard helper.
Signed-off-by: Akhilesh Patil
---
V1 -> V2: addressed review comments as below.
* inline - err = PTR_ERR(host->cl
On Fri, Aug 22, 2025 at 12:18:38PM +0900, Mikko Perttunen wrote:
> On Monday, July 28, 2025 9:15 AM Akhilesh Patil wrote:
> > Use dev_err_probe() helper as recommended by core driver model in
> > drivers/base/core.c to handle deferred probe error. Improve code
> > consistency and debuggability usin
On 8/21/25 23:06, David Hildenbrand wrote:
> All pages were already initialized and set to PageReserved() with a
> refcount of 1 by MM init code.
Just to be sure, how is this working with MEMBLOCK_RSRV_NOINIT, where MM is
supposed not to
initialize struct pages?
> In fact, by using __init_sin
From: Taotao Chen
Without O_LARGEFILE, file->f_op->write_iter calls
generic_write_check_limits(), which enforces a 2GB (MAX_NON_LFS) limit,
causing -EFBIG on large writes.
In shmem_pwrite(), this error is later masked as -EIO due to the error
handling order, leading to igt failures like gen9_exe
From: Taotao Chen
shmem_pwrite() currently checks for short writes before negative error
codes, which can overwrite real errors (e.g., -EFBIG) with -EIO.
Reorder the checks to return negative errors first, then handle short
writes.
Signed-off-by: Taotao Chen
Reviewed-by: Andi Shyti
---
v2:
-
On Monday, July 28, 2025 9:15 AM Akhilesh Patil wrote:
> Use dev_err_probe() helper as recommended by core driver model in
> drivers/base/core.c to handle deferred probe error. Improve code
> consistency and debuggability using standard helper.
>
> Signed-off-by: Akhilesh Patil
> ---
> drivers/g
On 2025/8/21 18:28, Dmitry Baryshkov wrote:
On Thu, Aug 21, 2025 at 11:35:57AM +0800, Yongxing Mou wrote:
Add compatible string for the DisplayPort controller found on the
Qualcomm QCS8300 SoC.
The Qualcomm QCS8300 platform comes with one DisplayPort controller
with same base offset as SM865
On 8/22/25 05:06, David Hildenbrand wrote:
> It's no longer required to use nth_page() when iterating pages within a
> single SG entry, so let's drop the nth_page() usage.
>
> Cc: Damien Le Moal
> Cc: Niklas Cassel
> Signed-off-by: David Hildenbrand
> ---
> drivers/ata/libata-sff.c | 6 +++---
Thu, Aug 21, 2025 at 03:30:30PM +0300, Dan Carpenter wrote:
> The devm_drm_bridge_alloc() function returns error pointers, it never
> returns NULL. Fix the checking to match.
>
> Fixes: dbdea37add13 ("drm: bridge: Add waveshare DSI2DPI unit driver")
> Signed-off-by: Dan Carpenter
Hi,
This chang
On 8/22/2025 12:25 AM, Akhil P Oommen wrote:
> From: Puranam V G Tejaswi
>
> Add gpu and gmu nodes for sa8775p chipset. As of now all
> SKUs have the same GPU fmax, so there is no requirement of
> speed bin support.
>
> Signed-off-by: Puranam V G Tejaswi
> Signed-off-by: Akhil P Oommen
> Revie
All pages were already initialized and set to PageReserved() with a
refcount of 1 by MM init code.
In fact, by using __init_single_page(), we will be setting the refcount to
1 just to freeze it again immediately afterwards.
So drop the __init_single_page() and use __ClearPageReserved() instead.
A
Several RISC-V boards feature Imagination GPUs that are compatible with
the PowerVR driver. An example is the IMG BXM-4-64 GPU on the Lichee Pi
4A board. This commit adjusts the driver's Kconfig dependencies to allow
the PowerVR driver to be compiled on the RISC-V architecture.
By enabling compila
From: Matthew Wilcox
It's not possible to replace object_name_lock as it protects more
code than should be reasonably be run under a spinlock, so the xa_lock
is nested under the object_name_lock.
Signed-off-by: Matthew Wilcox
Signed-off-by: Sidhartha Kumar
---
drivers/gpu/drm/drm_debugfs.c |
Applied to drm-misc-next.
Lizhi
On 8/21/25 05:52, Alex Deucher wrote:
On Wed, Aug 20, 2025 at 8:03 PM Lizhi Hou wrote:
The compiler information is outdated. Update it to the latest.
Signed-off-by: Lizhi Hou
Reviewed-by: Alex Deucher
---
Documentation/accel/amdxdna/amdnpu.rst | 10
Enable the following IPs on stm32mp257f-ev1 in order to get display:
* LTDC
* LVDS
* WSVGA LVDS panel (1024x600)
* Panel LVDS backlight as GPIO backlight
* ILI2511 i2c touchscreen
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 79 ++
Rework the PowerVR Rogue GPU binding to use an explicit, per variant
style for defining power domain properties and add support for the
T-HEAD TH1520 SoC's GPU.
To improve clarity and precision, the binding is refactored so that
power domain items are listed explicitly for each variant [1]. The
pr
Let's make it clearer that we are operating within a single folio by
providing both the folio and the page.
This implies that for flush_dcache_folio() we'll now avoid one more
page->folio lookup, and that we can safely drop the "nth_page" usage.
Cc: Thomas Bogendoerfer
Signed-off-by: David Hilde
Add a device tree node for the IMG BXM-4-64 GPU present in the T-HEAD
TH1520 SoC used by the Lichee Pi 4A board. This node enables support for
the GPU using the drm/imagination driver.
By adding this node, the kernel can recognize and initialize the GPU,
providing graphics acceleration capabilitie
Update the Imagination PVR DRM driver to leverage the pwrseq framework
for managing the complex power sequence of the GPU on the T-HEAD TH1520
SoC.
To cleanly separate platform-specific logic from the generic driver,
this patch introduces an `init` callback to the `pwr_power_sequence_ops`
struct.
This patch series introduces support for the Imagination IMG BXM-4-64
GPU found on the T-HEAD TH1520 SoC. A key aspect of this support is
managing the GPU's complex power-up and power-down sequence, which
involves multiple clocks and resets.
The TH1520 GPU requires a specific sequence to be follow
On 21.08.25 22:32, David Hildenbrand wrote:
On 21.08.25 22:06, David Hildenbrand wrote:
We want to get rid of nth_page(), and kfence init code is the last user.
Unfortunately, we might actually walk a PFN range where the pages are
not contiguous, because we might be allocating an area from memb
On 8/21/25 11:02, Matt Coster wrote:
> On 20/08/2025 18:08, Ulf Hansson wrote:
>> On Wed, 20 Aug 2025 at 10:56, Michal Wilczynski
>>> +#endif /* IS_ENABLED(CONFIG_POWER_SEQUENCING) */
>>
>> Yeah, this looks really messy to me.
>>
>> If there is something missing in the pwrseq interface to make t
Commit b0a2ee5567ab ("drm/xe: prepare xe_gen_wa_oob to be multi-use")
introduced a call to basename(). The GNU version of this function is not
portable and fails to build with alternative libc implementations like
musl or bionic. This causes the following build error:
drivers/gpu/drm/xe/xe_gen_w
syzbot ci has tested the following series
[v1] mm: remove nth_page()
https://lore.kernel.org/all/20250821200701.1329277-1-da...@redhat.com
* [PATCH RFC 01/35] mm: stop making SPARSEMEM_VMEMMAP user-selectable
* [PATCH RFC 02/35] arm64: Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP"
* [PATCH
On Thu, Aug 21, 2025 at 04:00:33PM -0500, Lucas De Marchi wrote:
>
> IMO the POSIX version is horrible. Let's add a xbasename() in this
> xe_gen_wa_oob.c and use it:
>
> /*
> * Avoid the libgen.h vs string.h differences or lack thereof, just use
> * our own.
> */
> static const char *xbasename
On 8/21/25 06:23, Xaver Hugl wrote:
We user space folks have been convinced at this point that the sRGB EOTF
is actually gamma 2.2, and not the piece-wise function. Now, if the
hardware is actually the piece-wise, then that's what should be exposed,
but I'm a bit unsure if we should do that un
The nth_page() is not really required anymore, so let's remove it.
While at it, cleanup and simplify the code a bit.
Signed-off-by: David Hildenbrand
---
fs/hugetlbfs/inode.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/
It's no longer required to use nth_page() within a folio, so let's just
drop the nth_page() in folio_walk_start().
Signed-off-by: David Hildenbrand
---
mm/pagewalk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index c6753d370ff4e..9e4225e5fcf
Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
is selected.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Signed-off-by: David Hildenbrand
---
arch/x86/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfi
Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
is selected.
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Alexander Gordeev
Cc: Christian Borntraeger
Cc: Sven Schnelle
Signed-off-by: David Hildenbrand
---
arch/s390/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/a
From: Puranam V G Tejaswi
Add gpu and gmu nodes for sa8775p chipset. As of now all
SKUs have the same GPU fmax, so there is no requirement of
speed bin support.
Signed-off-by: Puranam V G Tejaswi
Signed-off-by: Akhil P Oommen
Reviewed-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/lemans.
Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
is selected.
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: David Hildenbrand
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e9bbfacc35a64..b1d1f2ff2
On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
> Now that a single folio/compound page can no longer span memory sections
> in problematic kernel configurations, we can stop using nth_page().
>
> While at it, turn both macros into static inline functions and add
> kernel doc for folio_page_idx
With the small improvements, the core drm parts are
Reviewed-by: Sebastian Wick
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> This is an RFC set for a color pipeline API, along with implementations
> in VKMS and amdgpu. It is tested with a set of IGT tests that can be
> found at [1].
On Wed Aug 20, 2025 at 8:16 PM CEST, Alex Hung wrote:
>
>
> On 8/19/25 09:31, Sebastian Wick wrote:
>>> +/**
>>> + * drm_plane_colorop_curve_1d_lut_init - Initialize a DRM_COLOROP_1D_LUT
>>> + *
>>> + * @dev: DRM device
>>> + * @colorop: The drm_colorop object to initialize
>>> + * @plane: The asso
From: Matthew Wilcox
Convert tile_idr to an Xarray.
Signed-off-by: Matthew Wilcox
Signed-off-by: Sidhartha Kumar
---
drivers/gpu/drm/drm_connector.c | 26 ++
drivers/gpu/drm/drm_mode_config.c | 3 +--
include/drm/drm_mode_config.h | 12 ++--
3 files chan
On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
> Let's reject them early, which in turn makes folio_alloc_gigantic() reject
> them properly.
>
> To avoid converting from order to nr_pages, let's just add MAX_FOLIO_ORDER
> and calculate MAX_FOLIO_NR_PAGES based on that.
>
> Signed-off-by: David
On 21.08.25 22:55, Zi Yan wrote:
On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
Now that a single folio/compound page can no longer span memory sections
in problematic kernel configurations, we can stop using nth_page().
While at it, turn both macros into static inline functions and add
ke
On Wed, Aug 20, 2025 at 11:05:47PM +, Carlos Llamas wrote:
On Wed, Aug 20, 2025 at 04:15:47PM -0500, Lucas De Marchi wrote:
On Wed, Aug 20, 2025 at 08:16:11PM +, Carlos Llamas wrote:
> Commit b0a2ee5567ab ("drm/xe: prepare xe_gen_wa_oob to be multi-use")
> introduced a call to basename()
On 21.08.25 22:06, David Hildenbrand wrote:
We want to get rid of nth_page(), and kfence init code is the last user.
Unfortunately, we might actually walk a PFN range where the pages are
not contiguous, because we might be allocating an area from memblock
that could span memory sections in probl
ENERIC_PHY_MIPI_DPHY
+ select VIDEOMODE_HELPERS
depends on OF
help
Support Cadence DPI to DSI bridge. This is an internal
---
base-commit: 3f13bcc886fc034113cb75cb32b8d9db1216b846
change-id: 20250821-cdns-videohelpers-71182a6145bc
Best regards,
--
Nathan Chancellor
On 21 Aug 2025, at 16:49, David Hildenbrand wrote:
> On 21.08.25 22:46, Zi Yan wrote:
>> On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
>>
>>> Let's limit the maximum folio size in problematic kernel config where
>>> the memmap is allocated per memory section (SPARSEMEM without
>>> SPARSEMEM_V
On 21.08.25 22:46, Zi Yan wrote:
On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
Let's limit the maximum folio size in problematic kernel config where
the memmap is allocated per memory section (SPARSEMEM without
SPARSEMEM_VMEMMAP) to a single memory section.
Currently, only a single archit
It's no longer user-selectable (and the default was already "y"), so
let's just drop it.
Cc: "Jason A. Donenfeld"
Cc: Shuah Khan
Signed-off-by: David Hildenbrand
---
tools/testing/selftests/wireguard/qemu/kernel.config | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/
On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
> Let's limit the maximum folio size in problematic kernel config where
> the memmap is allocated per memory section (SPARSEMEM without
> SPARSEMEM_VMEMMAP) to a single memory section.
>
> Currently, only a single architectures supports ARCH_HAS_G
We're allocating a higher-order page from the buddy. For these pages
(that are guaranteed to not exceed a single memory section) there is no
need to use nth_page().
Signed-off-by: David Hildenbrand
---
mm/percpu-km.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/percpu-k
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: Maxim Levitsky
Cc: Alex Dubov
Cc: Ulf Hansson
Signed-off-by: David Hildenbrand
---
drivers/memstick/core/mspro_block.c | 3 +--
1 file changed, 1 insertion(+), 2 de
Hi Amirreza,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 5303936d609e09665deda94eaedf26a0e5c3a087]
url:
https://github.com/intel-lab-lkp/linux/commits/Amirreza-Zarrabi/tee-allow-a-driver-to-allocate-a-tee_device-without-a-pool/20250821-074358
base
On Thu, Aug 21, 2025 at 4:29 PM David Hildenbrand wrote:
> > Because doing a 64-bit shift on x86-32 is like three cycles. Doing a
> > 64-bit signed division by a simple constant is something like ten
> > strange instructions even if the end result is only 32-bit.
>
> I would have thought that the
On 21.08.25 22:29, David Hildenbrand wrote:
On 21.08.25 22:24, Linus Torvalds wrote:
On Thu, 21 Aug 2025 at 16:08, David Hildenbrand wrote:
- page = nth_page(page, offset >> PAGE_SHIFT);
+ page += offset / PAGE_SIZE;
Please keep the " >> PAGE_SHIFT" form.
No strong opinion.
I
On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
> Let's sanity-check in folio_set_order() whether we would be trying to
> create a folio with an order that would make it exceed MAX_FOLIO_ORDER.
>
> This will enable the check whenever a folio/compound page is initialized
> through prepare_compou
Oh, an your reply was an invalid email and ended up in my spam-box:
From: David Hildenbrand
but you apparently didn't use the redhat mail system, so the DKIM signing fails
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE)
header.from=redhat.com
and it gets marked as spam.
I thin
On Thu, 21 Aug 2025 at 16:08, David Hildenbrand wrote:
>
> - page = nth_page(page, offset >> PAGE_SHIFT);
> + page += offset / PAGE_SIZE;
Please keep the " >> PAGE_SHIFT" form.
Is "offset" unsigned? Yes it is, But I had to look at the source code
to make sure, because it wasn't local
On 21.08.25 22:24, Linus Torvalds wrote:
On Thu, 21 Aug 2025 at 16:08, David Hildenbrand wrote:
- page = nth_page(page, offset >> PAGE_SHIFT);
+ page += offset / PAGE_SIZE;
Please keep the " >> PAGE_SHIFT" form.
No strong opinion.
I was primarily doing it to get rid of (in oth
We want to get rid of nth_page(), and kfence init code is the last user.
Unfortunately, we might actually walk a PFN range where the pages are
not contiguous, because we might be allocating an area from memblock
that could span memory sections in problematic kernel configs (SPARSEMEM
without SPARS
Let's reject unreasonable folio sizes early, where we can still fail.
We'll add sanity checks to prepare_compound_head/prepare_compound_page
next.
Is there a way to configure a system such that unreasonable folio sizes
would be possible? It would already be rather questionable.
If so, we'd probab
On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
> In an ideal world, we wouldn't have to deal with SPARSEMEM without
> SPARSEMEM_VMEMMAP, but in particular for 32bit SPARSEMEM_VMEMMAP is
> considered too costly and consequently not supported.
>
> However, if an architecture does support SPARSEM
Add speedbin mappings for A663 GPU.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
index
00e1afd46b81546eec03e22cda9e9a604
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: Brett Creeley
Cc: Jason Gunthorpe
Cc: Yishai Hadas
Cc: Shameer Kolothum
Cc: Kevin Tian
Cc: Alex Williamson
Signed-off-by: David Hildenbrand
---
drivers/vfio/pci/
Document compatible string for the QFPROM on Lemans platform.
Signed-off-by: Akhil P Oommen
---
Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
b/Documentation/devicetree/bindin
From: Gaurav Kohli
Unlike the CPU, the GPU does not throttle its speed automatically when it
reaches high temperatures.
Set up GPU cooling by throttling the GPU speed
when reaching 105°C.
Signed-off-by: Gaurav Kohli
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 67
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: Herbert Xu
Cc: "David S. Miller"
Signed-off-by: David Hildenbrand
---
crypto/ahash.c | 4 ++--
crypto/scompress.c | 8
include/crypt
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: Maxim Levitsky
Cc: Alex Dubov
Cc: Ulf Hansson
Signed-off-by: David Hildenbrand
---
drivers/memstick/host/jmb38x_ms.c | 3 +--
drivers/memstick/host/tifm_ms.c | 3
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: Doug Gilbert
Signed-off-by: David Hildenbrand
---
drivers/scsi/scsi_lib.c | 3 +--
drivers/scsi/sg.c | 3 +
Now that all users are gone, let's remove it.
Signed-off-by: David Hildenbrand
---
include/linux/mm.h | 2 --
tools/testing/scatterlist/linux/mm.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f59ad1f9fc792..3ded0db8322f7 100
Ever since commit 858c708d9efb ("block: move the bi_size update out of
__bio_try_merge_page"), page_is_mergeable() no longer exists, and the
logic in bvec_try_merge_page() is now a simple page pointer
comparison.
Signed-off-by: David Hildenbrand
---
include/linux/bvec.h | 7 ++-
1 file chang
There is the concern that unpin_user_page_range_dirty_lock() might do
some weird merging of PFN ranges -- either now or in the future -- such
that PFN range is contiguous but the page range might not be.
Let's sanity-check for that and drop the nth_page() usage.
Signed-off-by: David Hildenbrand
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: Alex Dubov
Cc: Ulf Hansson
Cc: Jesper Nilsson
Cc: Lars Persson
Signed-off-by: David Hildenbrand
---
drivers/mmc/host/tifm_sd.c| 4 ++--
drivers/mmc/host/usdhi6
Within a folio/compound page, nth_page() is no longer required.
Given that we call folio_test_partial_kmap()+kmap_local_page(), the code
would already be problematic if the src_pages would span multiple folios.
So let's just assume that all src pages belong to a single
folio/compound page and can
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Simona Vetter
Signed-off-by: David Hildenbrand
---
drivers/gpu/drm/i915/
Let's limit the maximum folio size in problematic kernel config where
the memmap is allocated per memory section (SPARSEMEM without
SPARSEMEM_VMEMMAP) to a single memory section.
Currently, only a single architectures supports ARCH_HAS_GIGANTIC_PAGE
but not SPARSEMEM_VMEMMAP: sh.
Fortunately, the
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Cc: Damien Le Moal
Cc: Niklas Cassel
Signed-off-by: David Hildenbrand
---
drivers/ata/libata-sff.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --gi
The expectation is that there is currently no user that would pass in
non-contigous page ranges: no allocator, not even VMA, will hand these
out.
The only problematic part would be if someone would provide a range
obtained directly from memblock, or manually merge problematic ranges.
If we find su
We always provide a single dst page, it's unclear why the io_copy_cache
complexity is required.
So let's simplify and get rid of "struct io_copy_cache", simply working on
the single page.
... which immediately allows us for dropping one "nth_page" usage,
because it's really just a single page.
C
Let's disallow handing out PFN ranges with non-contiguous pages, so we
can remove the nth-page usage in __cma_alloc(), and so any callers don't
have to worry about that either when wanting to blindly iterate pages.
This is really only a problem in configs with SPARSEMEM but without
SPARSEMEM_VMEMM
dma_common_contiguous_remap() is used to remap an "allocated contiguous
region". Within a single allocation, there is no need to use nth_page()
anymore.
Neither the buddy, nor hugetlb, nor CMA will hand out problematic page
ranges.
Cc: Marek Szyprowski
Cc: Robin Murphy
Signed-off-by: David Hild
Let's sanity-check in folio_set_order() whether we would be trying to
create a folio with an order that would make it exceed MAX_FOLIO_ORDER.
This will enable the check whenever a folio/compound page is initialized
through prepare_compound_head() / prepare_compound_page().
Signed-off-by: David Hi
nth_page() is no longer required when iterating over pages within a
single folio, so let's just drop it when recording subpages.
Signed-off-by: David Hildenbrand
---
mm/gup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index b2a78f0291273..f017ff
Grepping for "prep_compound_page" leaves on clueless how devdax gets its
compound pages initialized.
Let's add a comment that might help finding this open-coded
prep_compound_page() initialization more easily.
Further, let's be less smart about the ordering of initialization and just
perform the
Now that a single folio/compound page can no longer span memory sections
in problematic kernel configurations, we can stop using nth_page().
While at it, turn both macros into static inline functions and add
kernel doc for folio_page_idx().
Signed-off-by: David Hildenbrand
---
include/linux/mm.
Let's check that no hstate that corresponds to an unreasonable folio size
is registered by an architecture. If we were to succeed registering, we
could later try allocating an unsupported gigantic folio size.
Further, let's add a BUILD_BUG_ON() for checking that HUGETLB_PAGE_ORDER
is sane at build
Let's reject them early, which in turn makes folio_alloc_gigantic() reject
them properly.
To avoid converting from order to nr_pages, let's just add MAX_FOLIO_ORDER
and calculate MAX_FOLIO_NR_PAGES based on that.
Signed-off-by: David Hildenbrand
---
include/linux/mm.h | 6 --
mm/page_alloc.
In an ideal world, we wouldn't have to deal with SPARSEMEM without
SPARSEMEM_VMEMMAP, but in particular for 32bit SPARSEMEM_VMEMMAP is
considered too costly and consequently not supported.
However, if an architecture does support SPARSEMEM with
SPARSEMEM_VMEMMAP, let's forbid the user to disable V
This is based on mm-unstable and was cross-compiled heavily.
I should probably have already dropped the RFC label but I want to hear
first if I ignored some corner case (SG entries?) and I need to do
at least a bit more testing.
I will only CC non-MM folks on the cover letter and the respective p
1 - 100 of 283 matches
Mail list logo
