From: Srinivasan Shanmugam
[ Upstream commit bf2ad4fb8adca89374b54b225d494e0b1956dbea ]
Return value of container_of(...) can't be null, so null check is not
required for 'fence'. Hence drop its NULL check.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c:93 to_amdgpu_amdkfd_fe
From: Rob Clark
[ Upstream commit 2b72e50c62de60ad2d6bcd86aa38d4ccbdd633f2 ]
When we start getting these, we get a *lot*. So ratelimit it to not
flood dmesg.
Signed-off-by: Rob Clark
Reviewed-by: Abhinav Kumar
Reviewed-by: Marijn Suijten
Patchwork: https://patchwork.freedesktop.org/patch/57
From: Josip Pavic
[ Upstream commit 6fb12518ca58412dc51054e2a7400afb41328d85 ]
[Why]
This variable currently overflows after about 71 minutes. This doesn't
cause any known functional issues but it does make debugging more
difficult.
[How]
Make it a 64-bit variable.
Reviewed-by: Aric Cyr
Acked
From: Felix Kuehling
[ Upstream commit ec9ba4821fa52b5efdbc4cdf0a77497990655231 ]
Change the rules for amdgpu_sync_resv to let KFD synchronize with VM
fences on page table reservations. This fixes intermittent memory
corruption after evictions when using amdgpu_vm_handle_moved to update
page tab
On Wed, Dec 6, 2023 at 12:49 PM Uwe Kleine-König
wrote:
>
> This prepares the pwm driver of the ti-sn65dsi86 to further changes of
> the pwm core outlined in the commit introducing devm_pwmchip_alloc().
> There is no intended semantical change and the driver should behave as
> before.
>
> Signed-o
On Fri, Nov 24, 2023 at 4:20 PM Alvin Šipraga wrote:
>
> From: Alvin Šipraga
>
> The adv7511 driver is solely responsible for setting the physical
> address of its CEC adapter. To do this, it must read the EDID. However,
> EDID is only read when either the drm_bridge_funcs :: get_edid or
> drm_co
On Sun, Nov 19, 2023 at 11:15 AM Heiner Kallweit wrote:
>
> After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
> olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
> Class-based device auto-detection is a legacy mechanism and shouldn't
> be used in new code.
On 22/01/2024 09:29, Dharma Balasubiramani wrote:
> Add a new LVDS controller driver for sam9x7 which does the following:
> - Prepares and enables the LVDS Peripheral clock
> - Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
> to the global bridge list.
> - Identifies its outp
On 2024-01-19 13:25, Ville Syrjälä wrote:
On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
AMD GPUs can do async flips with changes on more properties than just
the FB ID, so implement a custom check_async_props for AMD planes.
Allow amdgpu to do async flips with IN_FENCE_ID an
On 22/01/2024 09:29, Dharma Balasubiramani wrote:
> Add the 'sam9x7-lvds' compatible binding, which describes the
> Low Voltage Differential Signaling (LVDS) Controller found on Microchip's
> sam9x7 series System-on-Chip (SoC) devices. This binding will be used to
> define the properties and config
Hi Dharma
On Mon, Jan 22, 2024 at 03:52:17AM +, dharm...@microchip.com wrote:
> On 20/01/24 6:53 pm, Sam Ravnborg wrote:
> > [You don't often get email from s...@ravnborg.org. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > EXTERNAL EMAIL: Do not cli
Hi Dharma,
On Mon, Jan 22, 2024 at 03:52:17AM +, dharm...@microchip.com wrote:
> On 20/01/24 6:53 pm, Sam Ravnborg wrote:
> > [You don't often get email from s...@ravnborg.org. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > EXTERNAL EMAIL: Do not cl
From: Arnd Bergmann
Since commit d26270061ae6 ("string: Remove strlcpy()"), the strlcpy()
function causes a build failure.
Since the return value is ignored, changing it to the strscpy()
causes no change in behavior but fixes the build failure.
Fixes: f237c83e4302 ("drm: apple: DCP AFK/EPIC sup
On Monday, January 22, 2024 11:19:26 AM CET Daniel Thompson wrote:
> On Sat, Jan 20, 2024 at 10:26:43PM +0100, Duje Mihanović wrote:
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index 6292fddcc55c..d29b6823e7d1 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
On Monday, January 22, 2024 11:28:05 AM CET Daniel Thompson wrote:
> On Sat, Jan 20, 2024 at 10:26:45PM +0100, Duje Mihanović wrote:
> > diff --git a/drivers/video/backlight/ktd2801-backlight.c
> > b/drivers/video/backlight/ktd2801-backlight.c new file mode 100644
> > index ..7b9d1a93aa
Anything relating to GEM object management is placed here. Nothing
particularly interesting here, given the implementation is based on
drm_gem_shmem_object, which is doing most of the work.
v4:
- Force kernel BOs to be GPU mapped
- Make panthor_kernel_bo_destroy() robust against ERR/NULL BO pointe
Handles everything that's not related to the FW, the MMU or the
scheduler. This is the block dealing with the GPU property retrieval,
the GPU block power on/off logic, and some global operations, like
global cache flushing.
v4:
- Expose CORE_FEATURES through DEV_QUERY
v3:
- Add acks for the MIT/G
The panthor driver is designed in a modular way, where each logical
block is dealing with a specific HW-block or software feature. In order
for those blocks to communicate with each other, we need a central
panthor_device collecting all the blocks, and exposing some common
features, like interrupt
Every thing related to devfreq in placed in panthor_devfreq.c, and
helpers that can be called by other logical blocks are exposed through
panthor_devfreq.h.
This implementation is loosely based on the panfrost implementation,
the only difference being that we don't count device users, because
the
Tiler heap growing requires some kernel driver involvement: when the
tiler runs out of heap memory, it will raise an exception which is
either directly handled by the firmware if some free heap chunks are
available in the heap context, or passed back to the kernel otherwise.
The heap helpers will b
MMU and VM management is related and placed in the same source file.
Page table updates are delegated to the io-pgtable-arm driver that's in
the iommu subsystem.
The VM management logic is based on drm_gpuva_mgr, and is assuming the
VA space is mostly managed by the usermode driver, except for a
Now that all blocks are available, we can add/update Kconfig/Makefile
files to allow compilation.
v4:
- Add Steve's R-b
v3:
- Add a dep on DRM_GPUVM
- Fix dependencies in Kconfig
- Expand help text to (hopefully) describe which GPUs are to be
supported by this driver and which are for panfrost.
Add an entry for the Panthor driver to the MAINTAINERS file.
v4:
- Add Steve's R-b
v3:
- Add bindings document as an 'F:' line.
- Add Steven and Liviu as co-maintainers.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
MAINTAINERS | 11 +++
1 file changed, 11 insertions(+)
This is the last piece missing to expose the driver to the outside
world.
This is basically a wrapper between the ioctls and the other logical
blocks.
v4:
- Add an ioctl to let the UMD query the VM state
- Fix kernel doc
- Let panthor_device_init() call panthor_device_init()
- Fix cleanup orderin
Hello,
This is the 4th version of the kernel driver for Mali CSF-based GPUs.
A branch based on drm-misc-next and containing all the dependencies
that are not yet available in drm-misc-next here[1], and another [2]
containing extra patches to have things working on rk3588. The CSF
firmware binary
Panthor follows the lead of other recently submitted drivers with
ioctls allowing us to support modern Vulkan features, like sparse memory
binding:
- Pretty standard GEM management ioctls (BO_CREATE and BO_MMAP_OFFSET),
with the 'exclusive-VM' bit to speed-up BO reservation on job submission
- V
Those are the registers directly accessible through the MMIO range.
FW registers are exposed in panthor_fw.h.
v4:
- Add the CORE_FEATURES register (needed for GPU variants)
- Add Steve's R-b
v3:
- Add macros to extract GPU ID info
- Formatting changes
- Remove AS_TRANSCFG_ADRMODE_LEGACY - it doe
From: Liviu Dudau
Arm has introduced a new v10 GPU architecture that replaces the Job Manager
interface with a new Command Stream Frontend. It adds firmware driven
command stream queues that can be used by kernel and user space to submit
jobs to the GPU.
Add the initial schema for the device tre
Contains everything that's FW related, that includes the code dealing
with the microcontroller unit (MCU) that's running the FW, and anything
related to allocating memory shared between the FW and the CPU.
A few global FW events are processed in the IRQ handler, the rest is
forwarded to the schedu
This is the piece of software interacting with the FW scheduler, and
taking care of some scheduling aspects when the FW comes short of slots
scheduling slots. Indeed, the FW only expose a few slots, and the kernel
has to give all submission contexts, a chance to execute their jobs.
The kernel-side
Make it possible to use drm-bridge drivers on non-DT based systems.
Sui Jingfeng (5):
drm/bridge: Add drm_bridge_find_by_fwnode() helper
drm/bridge: simple-bridge: Extend match support for non-DT based
systems
drm/bridge: simple-bridge: Allow acquiring the next bridge with fwnode
API
On which case the driver is not probed by OF, Instead, a fwnode is
associated to the platform device before this driver is probed. The newly
added code is intended to be used on non-DT environment. It is assumed
that there is a string fwnode property associated with the platform device,
the name of
On 1/9/24 00:40, Alexey Makhalov wrote:
> +#ifdef CONFIG_INTEL_TDX_GUEST
> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
> +struct tdx_module_args *args)
> +{
> + if (!hypervisor_is_type(X86_HYPER_VMWARE))
> + return ULONG_MAX;
> +
> + if
From: Sui Jingfeng
Because API has wider coverage, it can be used on non-DT systems as well.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/display-connector.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/display-co
Because ACPI based systems only has the fwnode associated, the of_node
member of struct device is NULL. To order to move things forward, we add
drm_bridge_find_by_fwnode() to extend the support.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_bridge.c | 33 +
Which is intended to be used on non-DT environment, where the simple-bridge
platform device is created by either the display controller driver side or
platform firmware subsystem. To avoid duplication and to keep consistent,
we choose to reuse the OF match tables. Because the potentional user may
n
Which make it possible to use this driver on non-DT based systems,
meanwhile, made no functional changes for DT based systems.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/simple-bridge.c | 51 ++
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/dr
On Mon, 18 Dec 2023 21:25:16 +
Chris Diamand wrote:
> > +void panthor_fw_unplug(struct panthor_device *ptdev)
> > +{
> > + struct panthor_fw_section *section;
> > +
> > + cancel_delayed_work_sync(&ptdev->fw->watchdog.ping_work);
> > +
> > + /* Make sure the IRQ handler can be called aft
Hi Rob,
We didn't hear back from you, so I assumed you were happy with Liviu's
explanations and sent a v4 with just the s/space/tab/ formatting fix.
Please let us know if you have any concerns with v4 binding docs.
Thanks,
Boris
On Wed, 6 Dec 2023 10:59:38 +
Liviu Dudau wrote:
> Hi Rob,
>
On Mon, Jan 22, 2024 at 04:51:16PM +0100, Krzysztof Kozlowski wrote:
> On 22/01/2024 09:29, Dharma Balasubiramani wrote:
> > Add the 'sam9x7-lvds' compatible binding, which describes the
> > Low Voltage Differential Signaling (LVDS) Controller found on Microchip's
> > sam9x7 series System-on-Chip (
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video timi
Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
SoC and therefore use RZ/G2L fallback to avoid any driver changes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
v15->v16:
* No change.
v14->v15:
* No cha
This path series aims to add support for RZ/G2L DU DRM driver.
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video
signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
The output from DS
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support the blending of two picture layers and
raster operations (ROPs).
The DU mo
Create entry for Renesas RZ DRM drivers and add my self as a maintainer.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v15->v16:
* No change
v14->v15:
* Added drm-misc tree entry.
* Sorted the entry(Placed before SHMOBILE)
v13->v14:
* Now SHMOBILE has maintainer entries. So dropp
The rcar-du has never been maintained in drm-misc. So exclude only
this driver from drm-misc. Also, add the tree entry for sh_mobile.
Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven # shmob_drm
---
v15->v16:
* Added Rb and Ack tag from Geert.
v15:
* New pa
On Mon, Jan 22, 2024 at 05:24:51PM +0100, Duje Mihanović wrote:
> On Monday, January 22, 2024 11:19:26 AM CET Daniel Thompson wrote:
> > On Sat, Jan 20, 2024 at 10:26:43PM +0100, Duje Mihanović wrote:
> > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > > index 6292fddcc55c..d29b6823e
On Mon, Jan 22, 2024 at 05:24:56PM +0100, Duje Mihanović wrote:
> On Monday, January 22, 2024 11:28:05 AM CET Daniel Thompson wrote:
> > On Sat, Jan 20, 2024 at 10:26:45PM +0100, Duje Mihanović wrote:
> > > diff --git a/drivers/video/backlight/ktd2801-backlight.c
> > > b/drivers/video/backlight/ktd
On 1/20/24 09:10, Erick Archer wrote:
As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them ove
On Mon, Jan 22, 2024 at 10:08:05AM -0500, Sasha Levin wrote:
> From: Ville Syrjälä
>
> [ Upstream commit c6fbb6bca10838485b820e8a26c23996f77ce580 ]
Why is this being backported?
>
> The current implementation of drm_color_lut_extract()
> generates weird results. Eg. if we go through all the
>
On Monday, January 22, 2024 5:50:11 PM CET Daniel Thompson wrote:
> On Mon, Jan 22, 2024 at 05:24:51PM +0100, Duje Mihanović wrote:
> > I believe a "select" would be more appropriate here unless these
backlights
> > should be hidden if GPIOLIB is disabled. The catch with "select" is that
> > there
Hi,
On Thu, Jan 18, 2024 at 9:30 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jan 17, 2024 at 5:59 PM Hsin-Yi Wang wrote:
> >
> > Similar to commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> > is suspended in .post_disable()"). Add a mutex to ensure that aux transfer
> > won't race
On Tue, 14 Nov 2023, Bagas Sanjaya wrote:
> Stephen Rothwell reported htmldocs warnings when merging drm-intel
> tree:
>
> Documentation/gpu/drm-kms-helpers:296:
> drivers/gpu/drm/display/drm_dp_mst_topology.c:5484: ERROR: Unexpected
> indentation.
> Documentation/gpu/drm-kms-helpers:296:
> dri
Hi,
I've backported this two commits:
f9e96bf19054 drm/vmwgfx: Fix possible invalid drm gem put calls
91398b413d03 drm/vmwgfx: Keep a gem reference to user bos in surfaces
They both fixes a950b989ea29 ("drm/vmwgfx: Do not drop the reference
to the handle too soon")
which has been backported to v6
From: Zack Rusin
commit f9e96bf1905479f18e83a3a4c314a8dfa56ede2c upstream
vmw_bo_unreference sets the input buffer to null on exit, resulting in
null ptr deref's on the subsequent drm gem put calls.
This went unnoticed because only very old userspace would be exercising
those paths but it would
From: Zack Rusin
commit 91398b413d03660fd5828f7b4abc64e884b98069 upstream
Surfaces can be backed (i.e. stored in) memory objects (mob's) which
are created and managed by the userspace as GEM buffers. Surfaces
grab only a ttm reference which means that the gem object can
be deleted underneath us,
On Mon, 22 Jan 2024, Stephen Rothwell wrote:
>> [1]
>> https://patchwork.freedesktop.org/patch/msgid/20231114081033.27343-1-bagasdo...@gmail.com
>
> This is still not fixed.
Thanks for the reminder. Commit 1a84c213146a ("drm/dp_mst: Separate
@failing_port list in drm_dp_mst_atomic_check_mgr() co
On Monday, January 22, 2024 5:57:53 PM CET Duje Mihanović wrote:
> On Monday, January 22, 2024 5:50:11 PM CET Daniel Thompson wrote:
> > AFAICT nothing will inhibit setting GPIOLIB so allyes- and allmodconfig
> > builds will always end up with GPIOLIB enabled. If we are happy to
> > select it then
On 1/19/2024 6:31 PM, Dmitry Baryshkov wrote:
On Fri, 19 Jan 2024 at 23:14, Kuogee Hsieh wrote:
Dmitry,
I am testing this patch serial with msm-next branch.
This patch cause system crash during booting up for me.
Is this patch work for you?
Yes, tested on top of linux-next. However I only
On Mon, Jan 22, 2024 at 06:26:04PM +0100, Duje Mihanović wrote:
> On Monday, January 22, 2024 5:57:53 PM CET Duje Mihanović wrote:
> > On Monday, January 22, 2024 5:50:11 PM CET Daniel Thompson wrote:
> > > AFAICT nothing will inhibit setting GPIOLIB so allyes- and allmodconfig
> > > builds will al
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Signed-off-by: Uwe Kleine-König
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Signed-off-by: Uwe Kleine-König
Hello,
this is v2 of this patch set.
Changes since (implicit) v1, sent with Message-Id:
cover.1705348269.git.u.kleine-koe...@pengutronix.de:
- Rebase to v6.8-rc1
- Fix a build failure on sh
- Added the tags received in (implicit) v1.
The slave-mt27xx driver needs some more work. The patch pr
On Mon, Jan 22, 2024 at 01:41:21PM +0200, Sakari Ailus wrote:
> There are two ways to opportunistically increment a device's runtime PM
> usage count, calling either pm_runtime_get_if_active() or
> pm_runtime_get_if_in_use(). The former has an argument to tell whether to
> ignore the usage count or
On Monday, January 22, 2024 6:50:31 PM CET Daniel Thompson wrote:
> On Mon, Jan 22, 2024 at 06:26:04PM +0100, Duje Mihanović wrote:
> > On Monday, January 22, 2024 5:57:53 PM CET Duje Mihanović wrote:
> > > On Monday, January 22, 2024 5:50:11 PM CET Daniel Thompson wrote:
> > > > AFAICT nothing wil
On Mon, Jan 22, 2024 at 7:12 PM Bjorn Helgaas wrote:
>
> On Mon, Jan 22, 2024 at 01:41:21PM +0200, Sakari Ailus wrote:
> > There are two ways to opportunistically increment a device's runtime PM
> > usage count, calling either pm_runtime_get_if_active() or
> > pm_runtime_get_if_in_use(). The forme
On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
> Note that Jonathan Cameron has already applied patch 3 to his tree, it
> didn't appear in a public tree though yet. I still included it here to
> make the kernel build bots happy.
It's also going to be needed for buildability of
On January 22, 2024 8:32:22 AM PST, Dave Hansen wrote:
>On 1/9/24 00:40, Alexey Makhalov wrote:
>> +#ifdef CONFIG_INTEL_TDX_GUEST
>> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
>> + struct tdx_module_args *args)
>> +{
>> +if (!hypervisor_is_type(X86_HYP
On Mon, Jan 22, 2024 at 06:10:11PM +0100, Jocelyn Falempe wrote:
> Hi,
>
> I've backported this two commits:
> f9e96bf19054 drm/vmwgfx: Fix possible invalid drm gem put calls
> 91398b413d03 drm/vmwgfx: Keep a gem reference to user bos in surfaces
>
> They both fixes a950b989ea29 ("drm/vmwgfx: Do
On Mon, 22 Jan 2024 18:18:22 +
Mark Brown wrote:
> On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
>
> > Note that Jonathan Cameron has already applied patch 3 to his tree, it
> > didn't appear in a public tree though yet. I still included it here to
> > make the kernel bui
Hello,
This series adds support for the Kinetic KTD2801 LED backlight driver
IC found in samsung,coreprimevelte.
Support is already upstream for the somewhat similar KTD2692 flash
driver, and this series since v3 also moves its ExpressWire code into a
separate library and converts the KTD2692 dri
KTD2801 is a LED backlight driver IC found in samsung,coreprimevelte.
The brightness can be set using PWM or the ExpressWire protocol. Add
support for the KTD2801.
Reviewed-by: Linus Walleij
Signed-off-by: Duje Mihanović
---
MAINTAINERS | 6 ++
drivers/video/ba
KTD2801 is a LED backlight driver IC found in samsung,coreprimevelte.
The brightness can be set using PWM or the ExpressWire protocol. Add
a DT binding for the KTD2801.
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Linus Walleij
Signed-off-by: Duje Mihanović
---
.../bindings/leds/backlight/kin
The ExpressWire protocol is shared between at least KTD2692 and KTD2801
with slight differences such as timings and the former not having a
defined set of pulses for enabling the protocol (possibly because it
does not support PWM unlike KTD2801). Despite these differences the
ExpressWire handling c
On 1/22/24 12:03, Jiri Slaby (SUSE) wrote:
Push the console code (vt.c, vt.h, console.h, ...) into a bit more
maintainable state. Especially all around consw structure and document
it.
CSI parser is also a bit cleaned up. More to follow some time in the
next round.
I've not yet looked through
Reformat lines in kernel-doc comments, which make use of the backslash at
the end to suggest it is a multi-line comment. kernel-doc is able to
process e.g. the short description of a function properly, even if it is
across two lines.
No functional change.
Signed-off-by: Anna-Maria Behnsen
Review
Hi,
this is a repost of the RFC queue
https://lkml.kernel.org/r/20240116151456.48238-1-anna-ma...@linutronix.de
Jonathan Corbet is fine with this change and mentioned in an answer the
following:
"The kernel-doc change should really go together with the DRM change.
I'm happy to carry both wit
Commit 654784284430 ("kernel-doc: bugfix - multi-line macros") introduces
pre-processing of backslashes at the end of a line to not break multi-line
macros. This pre-processing is done independently if it is inside code or
inside a comment.
This illustation of a hierarchy as a code block inside a
The constraints for 'audio-ports' don't match the description. There can
be 1 or 2 DAI entries and each entry is exactly 2 values. Also, the
values' sizes are 32-bits, not 8-bits. Move the size constraints to the
outer dimension (number of DAIs) and add constraints on inner array
values.
Signed-of
Hej,
On Mon, Jan 22, 2024, at 17:11, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Since commit d26270061ae6 ("string: Remove strlcpy()"), the strlcpy()
> function causes a build failure.
>
> Since the return value is ignored, changing it to the strscpy()
> causes no change in behavior but fixes
Hej,
On Wed, Jan 17, 2024, at 11:44, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With linux-6.8, the kernel warns about functions that have no
> extern declaration, so mark both of these static.
>
> Fixes: 2d782b0d007d ("gpu: drm: apple: Add sound mode parsing")
> Signed-off-by: Arnd Bergmann
On Mon, Jan 22, 2024 at 03:04:42PM +0100, Janusz Krzysztofik wrote:
> Object debugging tools were sporadically reporting illegal attempts to
> free a still active i915 VMA object when parking a GPU tile believed to be
> idle.
>
> [161.359441] ODEBUG: free active (active state 0) object: 888116
On 22/01/2024 16:34, Boris Brezillon wrote:
> On Mon, 18 Dec 2023 21:25:16 +
> Chris Diamand wrote:
>
>>> +void panthor_fw_unplug(struct panthor_device *ptdev)
>>> +{
>>> + struct panthor_fw_section *section;
>>> +
>>> + cancel_delayed_work_sync(&ptdev->fw->watchdog.ping_work);
>>> +
>>>
On Mon, Jan 22, 2024 at 03:04:43PM +0100, Janusz Krzysztofik wrote:
> This reverts changes introduced by commit f56fe3e91787, obsoleted by
> "drm/i915/vma: Fix UAF on destroy against retire race".
I believe the good chunk of the first commit message should be moved
here instead.
But why did you d
On 1/22/24 16:04, Geert Uytterhoeven wrote:
If the boot logo does not fit, a message is printed, including a wrong
function name prefix. Instead of correcting the function name (or using
__func__), just use "fbcon", like is done in several other messages.
While at it, modernize the call by swit
On 1/22/24 11:20, Uwe Kleine-König wrote:
On Thu, Jan 18, 2024 at 09:04:05PM +0100, Mirsad Todorovac wrote:
On 1/18/24 08:45, Uwe Kleine-König wrote:
Hello Mirsad,
On Wed, Jan 17, 2024 at 07:47:49PM +0100, Mirsad Todorovac wrote:
On 1/16/24 01:32, Mirsad Todorovac wrote:
On the Ubuntu 2
On 22. 01. 2024. 09:34, Ma, Jun wrote:
> Perhaps similar to the problem I encountered earlier, you can
> try the following patch
>
> https://lists.freedesktop.org/archives/amd-gfx/2024-January/103259.html
Appaarently, this patch prevented NULL dereference, it was no longer in the log.
However, t
On 1/16/2024 9:58 AM, Baruch Siach wrote:
Hi qaic driver maintainers,
Sorry I was holiday last week and I am just now catching up on email and
seeing this.
I am testing an A100 device on arm64 platform. Kernel version is current
Linus master as of commit 052d534373b7. The driver is unable t
On 1/16/24 13:31, Dan Carpenter wrote:
On Tue, Jan 16, 2024 at 11:16:09AM +, Colin Ian King wrote:
The variable ret is being assigned a value but it isn't being
read afterwards. The assignment is redundant and so ret can be
removed.
Cleans up clang scan build warning:
warning: Although the
I just kicked off testing some patches on top of 6.8-rc1 and triggered this
immediately:
[ note this happened on both my 32 bit an 64 bit test machines, this is
just the 32 bit output ]
BUG: kernel NULL pointer dereference, address: 0238
#PF: supervisor read access in kernel mode
#PF: er
On Mon, 22 Jan 2024 18:06:05 -0500
Steven Rostedt wrote:
> qxl_ttm_init+0x34/0x130
>
> int ttm_device_init(struct ttm_device *bdev, const struct ttm_device_funcs
> *funcs,
> struct device *dev, struct address_space *mapping,
> struct drm_vma_offset_manag
On Mon, 22 Jan 2024 18:15:47 -0500
Steven Rostedt wrote:
> > ttm_pool_init(&bdev->pool, dev, dev_to_node(dev), use_dma_alloc,
> > use_dma32); <<<--- BUG!
> >
> > Specifically, it appears that dev is NULL and dev_to_node() doesn't like
> > having a NULL pointer passed to it.
> >
>
>
On 1/22/24 10:28 AM, H. Peter Anvin wrote:
On January 22, 2024 8:32:22 AM PST, Dave Hansen wrote:
On 1/9/24 00:40, Alexey Makhalov wrote:
+#ifdef CONFIG_INTEL_TDX_GUEST
+unsigned long vmware_tdx_hypercall(unsigned long cmd,
+ struct tdx_module_args *args)
+{
On January 22, 2024 4:04:33 PM PST, Alexey Makhalov
wrote:
>
>
>On 1/22/24 10:28 AM, H. Peter Anvin wrote:
>> On January 22, 2024 8:32:22 AM PST, Dave Hansen
>> wrote:
>>> On 1/9/24 00:40, Alexey Makhalov wrote:
+#ifdef CONFIG_INTEL_TDX_GUEST
+unsigned long vmware_tdx_hypercall(unsign
In an effort to separate intentional arithmetic wrap-around from
unexpected wrap-around, we need to refactor places that depend on this
kind of math. One of the most common code patterns of this is:
VAR + value < VAR
Notably, this is considered "undefined behavior" for signed and pointer
In an effort to separate intentional arithmetic wrap-around from
unexpected wrap-around, we need to refactor places that depend on this
kind of math. One of the most common code patterns of this is:
VAR + value < VAR
Notably, this is considered "undefined behavior" for signed and pointer
On 1/22/2024 6:06 PM, Steven Rostedt wrote:
I just kicked off testing some patches on top of 6.8-rc1 and triggered this
immediately:
[ note this happened on both my 32 bit an 64 bit test machines, this is
just the 32 bit output ]
BUG: kernel NULL pointer dereference, address: 0238
#
On Mon, 22 Jan 2024 19:29:41 -0500
"Bhardwaj, Rajneesh" wrote:
>
> In one of my previous revisions of this patch when I was experimenting,
> I used something like below. Wonder if that could work in your case
> and/or in general.
>
>
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> b/drive
In an effort to separate intentional arithmetic wrap-around from
unexpected wrap-around, we need to refactor places that depend on this
kind of math. One of the most common code patterns of this is:
VAR + value < VAR
Notably, this is considered "undefined behavior" for signed and pointer
In an effort to separate intentional arithmetic wrap-around from
unexpected wrap-around, we need to refactor places that depend on this
kind of math. One of the most common code patterns of this is:
VAR + value < VAR
Notably, this is considered "undefined behavior" for signed and pointer
201 - 300 of 334 matches
Mail list logo
