On Tue, Feb 04, 2025 at 03:58:02PM +0100, Maxime Ripard wrote:
> The tc358768 driver follows the drm_encoder->crtc pointer that is
> deprecated and shouldn't be used by atomic drivers.
>
> This was due to the fact that we did't have any other alternative to
> retrieve the CRTC pointer. Fortunately
On Tue, Feb 04, 2025 at 03:58:01PM +0100, Maxime Ripard wrote:
> The tc358775 driver follows the drm_encoder->crtc pointer that is
> deprecated and shouldn't be used by atomic drivers.
>
> This was due to the fact that we did't have any other alternative to
> retrieve the CRTC pointer. Fortunately
On Tue, Feb 04, 2025 at 03:58:00PM +0100, Maxime Ripard wrote:
> The Cadence DSI driver follows the drm_encoder->crtc pointer that is
> deprecated and shouldn't be used by atomic drivers.
>
> This was due to the fact that we did't have any other alternative to
> retrieve the CRTC pointer.
See bel
On Tue, Feb 04, 2025 at 03:57:59PM +0100, Maxime Ripard wrote:
> Other entities (drm_connector.crtc, drm_encoder.crtc, etc.) have
> pointer to other currently bound entities. They are all considered
> relevant only for non-atomic drivers, and generally perceived as
> deprecated in favour of the equ
On Tue, Feb 04, 2025 at 03:57:58PM +0100, Maxime Ripard wrote:
> Now that connectors are no longer necessarily created by the bridges
> drivers themselves but might be created by drm_bridge_connector, it's
> pretty hard for bridge drivers to retrieve pointers to the connector and
> CRTC they are at
Andrew - apologies for this, I managed to miss some unusued variable warnings in
this nommu workaround, once you take the v3 could you apply this trivial
fix-patch on top to resolve that?
I tested this locally to confirm it resolves the problem. Thanks!
8<
>From f428a950a5a932c0e4404a89f2
On Tue, Feb 04, 2025 at 03:57:55PM +0100, Maxime Ripard wrote:
> The drm_bridge structure contains an encoder pointer that is widely used
> by bridge drivers. This pattern is largely documented as deprecated in
> other KMS entities for atomic drivers.
>
> However, one of the main use of that point
On Tue, Feb 04, 2025 at 03:57:57PM +0100, Maxime Ripard wrote:
> A bridge is considered atomic-enabled if it has an atomic_check
I think this part of the explanation is a bit misleading. This code just
checks if there is a need to atomic_check() it.
> implementation. However, atomic_check is opti
On Tue, Feb 04, 2025 at 03:57:56PM +0100, Maxime Ripard wrote:
> The current bridge state is accessible from the drm_bridge structure,
> but since it's fairly indirect it's not easy to figure out.
>
> Provide a helper to retrieve it.
>
> Signed-off-by: Maxime Ripard
> ---
> include/drm/drm_brid
On Tue, Feb 04, 2025 at 03:57:43PM +0100, Maxime Ripard wrote:
> crtc_set_mode() deals with calling the modeset related hooks for CRTC,
> connectors and bridges if and when a new commit changes them. It takes
> the drm_atomic_state being committed as a parameter.
>
> However, that parameter name i
On Tue, Feb 04, 2025 at 03:57:42PM +0100, Maxime Ripard wrote:
> drm_atomic_helper_update_legacy_modeset_state() updates all the legacy
> modeset pointers a connector, encoder or CRTC might have with the ones
> being setup by a given commit. It takes the drm_atomic_state being
> committed as a para
As these clocks are now used in the runtime PM callbacks, they have no
connection to 'HPD'. Rename corresponding fields to follow clocks
purpose, to power up the HDMI controller.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 26 +---
The HDMI driver already has msm_hdmi_hpd_enable() and
msm_hdmi_hpd_disable() functions. Wire them into the
msm_hdmi_bridge_funcs, so that HPD can be enabled and disabled
dynamically rather than always having HPD events generation enabled.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshko
There is no need to specify separate HPD gpio for the HDMI block. Use
built-in HPD in order to detect if the monitor is plugged or not.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qc
Supporting simultaneous check of native HPD and the external GPIO proved
to be less stable than just native HPD. Drop the hpd-gpios support,
leaving just the native HPD support. In case the native HPD doesn't work
the user is urged to switch to specifying the HPD property to the
hdmi-connector devi
The HDMI block needs to be enabled to properly generate HPD events. Make
sure it is not turned off in the disable paths if HPD delivery is enabled.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 1 +
drivers/gpu/drm/msm/hdmi/hdmi.h
Expand the HDMI_CFG() macro in HDMI config description. It has no added
value other than hiding some boilerplate declarations.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 16
drivers/gpu/drm/msm/hdmi/hdmi.h | 2 +-
2 files c
It is completely not obvious, but the so-called 'hpd' clocks and
regulators are required for the HDMI host to function properly. Merge
pwr and hpd regulators. Use regulators, clocks and pinctrl to implement
proper runtime PM callbacks.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
-
We must be sure that the HDMI controller is powered on, while performing
the DDC transfer. Add corresponding runtime PM calls to
msm_hdmi_i2c_xfer().
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_i2c.c | 14 --
1 file changed, 12 insert
The pm_runtime_get_sync() function is a bad choise for runtime power
management. Switch HDMI driver to pm_runtime_resume_and_get() and add
proper error handling, while we are at it.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 2 +-
dr
With the extp being the only "power" clock left, remove the surrounding
loops and handle the extp clock directly.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 24
drivers/gpu/drm/msm/hdmi/hdmi.h| 6 +---
As a preparation to the next patches convert 'static const char *'
arrays to 'static const char * const', as required by the checkpatch.pl
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 10 +-
drivers/gpu/drm/msm/hdmi/hdmi.h | 8
2 files changed, 9 insert
The last platform using legacy clock names for HDMI block (APQ8064)
switched to new clock names in 5.16. It's time to stop caring about old
DT, drop hand-coded helpers and switch to clk_bulk_* API.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c
The only clock which has frequency being set through hpd_freqs is the
"core" aka MDSS_HDMI_CLK clock. It always has the specified frequency,
so we can drop corresponding clk_set_rate() call together with the
hpd_freq infrastructure.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
The commit 68e674b13b17 ("drm/msm/hdmi: drop unused GPIO support")
dropped support for obsolete qcom,hdmi-tx-mux-* gpios. They were not
used by any of the upstream platforms. Drop them from the bindings too.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/hdmi.y
According to the vendor kernel [1] , the alt_iface clock should be
enabled together with the rest of HPD clocks, to make HPD to work
properly.
[1]
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/commit/e07a5487e521e57f76083c0a6e2f995414ac6d03
Reviewed-by: Jessica Zhang
Reviewed-by: Konrad D
Supporting simultaneous check of native HPD and the external GPIO proved
to be less stable than just native HPD. Drop the hpd-gpios from the
bindings. This is not a breaking change, since the HDMI block has been
using both GPIO _and_ internal HPD anyway. In case the native HPD
doesn't work users ar
The MSM HDMI driver is plagued with the long-standing bug. If HDMI cable
is disconnected, in most of the cases cable reconnection will not be
detected properly. We have been carrying the patch from [1] in our
integration tree for ages. The time has come to fix the long-standing
bug and implement pr
On Thu, Jan 23, 2025 at 12:12:43PM +0200, Jani Nikula wrote:
> On Thu, 23 Jan 2025, Dmitry Baryshkov wrote:
> > On Fri, Jan 17, 2025 at 10:56:35AM +0200, Dmitry Baryshkov wrote:
> >> Existing DPCD access functions return an error code or the number of
> >> bytes being read / write in case of parti
On Mon, Jan 13, 2025 at 11:53:43AM +0200, Dmitry Baryshkov wrote:
> TDA998x is the HDMI bridge driver, incorporating drm_connector and
> optional drm_encoder (created via the component bind API by the TICLDC
> and HDLCD drivers). TDA9950 is an I2C-CEC translator, being present
> on-die on the TDA99
Change debugfs and log entries to use KBps / u32 for bw_ctl and similar
data.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 5 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 ++-
2 files changed, 5 insertions(+), 3 deleti
core_clk_rate override is handled in _dpu_core_perf_get_core_clk_rate().
Drop imperfect duplicating code from _dpu_core_perf_calc_crtc().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drive
On Tue, Feb 04, 2025 at 03:57:28PM +0100, Maxime Ripard wrote:
> Hi,
>
> Here's a series of changes after to the KMS helpers and bridge API
> following a bunch of reviews I did.
>
> It's mostly centered across providing an easier time to deal with bridge
> states, and a somewhat consistent with t
Move perf mode handling for the bandwidth to
_dpu_core_perf_crtc_update_bus() rather than overriding per-CRTC data
and then aggregating known values.
Note, this changes the fix_core_ab_vote. Previously it would be
multiplied per the CRTC number, now it will be used directly for
interconnect voting
In preparation to refactoring the dpu_core_perf debugfs interface,
extract the bandwidth aggregation function from
_dpu_core_perf_crtc_update_bus().
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 45 +++
1 f
Rename the debugfs files to match their purpose and the patter provided
by other bandwidth and clock-related files:
threshold_high -> max_core_ab
threshold_low -> low_core_ab
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 ++--
The fix_core_ab_vote is an average bandwidth value, used for bandwidth
overrides in several cases. However there is an internal inconsistency:
fix_core_ib_vote is defined in KBps, while fix_core_ab_vote is defined
in Bps.
Fix that by changing the type of the variable to u32 and using * 1000ULL
mul
The IB values in core_perf calculations (max_per_pipe_ib,
fix_core_ib_vote) are expressed in KBps and are passed to icc_set_bw
without additional division. Change type of those values to u32.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_p
The code in dpu_core_perf_crtc_check() mostly duplicates code in
dpu_core_perf_aggregate(). Remove the duplication by reusing the latter
function.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 94 +++
1 fil
Bring back a set of patches extracted from [1] per Abhinav's suggestion.
Rework debugging overrides for the bandwidth and clock settings. Instead
of specifying the 'mode' and some values, allow one to set the affected
value directly.
[1] https://patchwork.freedesktop.org/series/119552/#rev2
Sign
On Tue, Feb 04, 2025 at 03:57:40PM +0100, Maxime Ripard wrote:
> drm_atomic_bridge_chain_disable() disables all bridges affected by a new
> commit. It takes the drm_atomic_state being committed as a parameter.
>
> However, that parameter name is called (and documented) as old_state,
> which is pre
On Tue, Feb 04, 2025 at 03:57:39PM +0100, Maxime Ripard wrote:
> disable_outputs() disables all connectors and CRTCs affected by a
> commit. It takes the drm_atomic_state being committed as a parameter.
>
> However, that parameter name is called as old_state, which is pretty
> confusing. Let's ren
On Tue, Feb 04, 2025 at 03:57:38PM +0100, Maxime Ripard wrote:
> drm_atomic_helper_modeset_disables() disables all the outputs affected
> by a commit. It takes the drm_atomic_state being committed as a
> parameter.
>
> However, that parameter name is called (and documented) as old_state,
> which i
On Tue, Feb 04, 2025 at 03:57:37PM +0100, Maxime Ripard wrote:
> drm_atomic_helper_commit_tail_rpm() is the final part of an atomic
> commit, and is given the state being committed as a parameter.
>
> However, that parameter is named old_state, but documented as the "new
> modeset state" which is
On Tue, Feb 04, 2025 at 03:57:36PM +0100, Maxime Ripard wrote:
> drm_atomic_helper_commit_tail() is the final part of an atomic commit,
> and is given a parameter with the drm_atomic_state being committed.
>
> However, that parameter name is called (and documented) as old_state,
> which is pretty
On Tue, Feb 04, 2025 at 03:57:35PM +0100, Maxime Ripard wrote:
> drm_atomic_helper_wait_for_dependencies() waits for all the dependencies
> a commit has before going forward with it. It takes the drm_atomic_state
> being committed as a parameter.
>
> However, that parameter name is called (and doc
On Mon, 27 Jan 2025 08:10:02 +0100, Arnd Bergmann wrote:
> Without the DP helper code, the newly added displayport support
> causes a link failure:
>
> x86_64-linux-ld: drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.o: in function
> `hibmc_dp_aux_init':
> dp_aux.c:(.text+0x37e): undefined reference to
On Tue, Feb 04, 2025 at 03:57:34PM +0100, Maxime Ripard wrote:
> Even though the commit_tail () drm_atomic_state parameter is called
> old_state, it's actually the state being committed which is confusing.
>
> It's even more confusing since the atomic_commit_tail hook being called
> by commit_tail
Ted,
On Sat, Feb 08, 2025 at 03:44:16PM -0500, Theodore Ts'o wrote:
> This was the trust of my "Beyond Upstream First" presentation which I
> gave to the Linux Foundation Member Summit last fall[1].
>
> [1]
> https://docs.google.com/presentation/d/11rMc8PBeyMItV6hv31OHSZ626_6FCZxjX6ZxEAehCpQ/edi
On Sat, Feb 08, 2025 at 11:09:56PM +0100, Marijn Suijten wrote:
> On 2025-02-03 21:14:26, Danila Tikhonov wrote:
> > From: Eugene Lepshy
> >
> > DRM DSC helper has parameters for various bpc values other than 8:
>
> Weird zero-width \u200b spaces here between "values" and "other", please
> de
On 2025-02-03 21:14:26, Danila Tikhonov wrote:
> From: Eugene Lepshy
>
> DRM DSC helper has parameters for various bpc values other than 8:
Weird zero-width \u200b spaces here between "values" and "other", please delete
those.
> (8/10/12/14/16).
>
> Remove this guard.
>
> Signed-off-by: Eug
On Sat, Feb 08, 2025 at 12:18:47PM -0800, Doug Anderson wrote:
> Hi,
>
> On Fri, Feb 7, 2025 at 9:16 PM Tejas Vipin wrote:
> >
> > Change the visionox-r66451 panel to use multi style functions for
> > improved error handling.
> >
> > Signed-off-by: Tejas Vipin
> > ---
> > drivers/gpu/drm/panel/
On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
>
> The all powerful sub-system maintainer model works well if the big
> technology companies can employ omniscient individuals in these roles,
> but those types are a bit hard to come by.
I'll let you in a secret. The maintainers are not
Hi,
On Thu, Feb 6, 2025 at 1:06 PM Anusha Srivatsa wrote:
>
> Transition away from mipi_dsi_generic_write_seq() and
> mipi_dsi_dcs_write_seq() to mipi_dsi_generic_write_seq_multi()
> and mipi_dsi_dcs_write_seq_multi() respectively.
>
> This is addressing one of the gpu todo items [1]
>
> Used Coc
Hi,
On Sat, Feb 8, 2025 at 2:53 AM Langyan Ye
wrote:
>
> The kingdisplay-kd110n11-51ie is a 10.95" TFT panel. The MIPI controller
> on this panel is the same as the other panels here, so add this panel
> to this driver.
>
> Signed-off-by: Langyan Ye
> ---
> drivers/gpu/drm/panel/panel-himax-hx8
Hi,
On Sat, Feb 8, 2025 at 2:53 AM Langyan Ye
wrote:
>
> Add a new compatible for the panels KINGDISPLAY KD110N11-51IE and
> STARRY 2082109QFH040022-50E. Both panels use the HX83102 IC, so
> add the compatible to the hx83102 bindings file.
>
> Signed-off-by: Langyan Ye
> ---
> .../devicetree/bi
Hi,
On Sat, Feb 8, 2025 at 2:53 AM Langyan Ye
wrote:
>
> The starry-2082109qfh040022-50e is a 10.95" TFT panel. The MIPI controller
> on this panel is the same as the other panels here, so add this panel to
> this driver.
>
> Signed-off-by: Langyan Ye
> ---
> drivers/gpu/drm/panel/panel-himax-h
Hi,
On Fri, Feb 7, 2025 at 9:16 PM Tejas Vipin wrote:
>
> Change the visionox-r66451 panel to use multi style functions for
> improved error handling.
>
> Signed-off-by: Tejas Vipin
> ---
> drivers/gpu/drm/panel/panel-visionox-r66451.c | 179 --
> 1 file changed, 76 insertions(+
On Sat, Feb 08, 2025 at 05:44:14PM +0800, Huang, Honglei1 wrote:
> On 2025/2/8 10:43, Demi Marie Obenour wrote:
> > On Fri, Feb 07, 2025 at 09:30:45PM -0500, Demi Marie Obenour wrote:
> > > On Fri, Feb 07, 2025 at 07:07:11PM +0800, Huang, Honglei1 wrote:
> > > > On 2025/2/7 2:21, Demi Marie Obenour
> devm_kasprintf() can return a NULL pointer on failure,but this
> returned value in zynqmp_audio_init() is not checked.
Another wording suggestion:
devm_kasprintf() calls can return null pointers on failure.
But some return values were not checked in zynqmp_audio_init().
> Add NULL check in zyn
With the introduction of mapping_wrprotect_range() there is no need to use
folio_mkclean() in order to write-protect mappings of frame buffer pages,
and therefore no need to inappropriately set kernel-allocated page->index,
mapping fields to permit this operation.
Instead, store the pointer to the
In order to permit the traversal of the reverse mapping at a specified
mapping and offset rather than those specified by an input folio, we need
to separate out the portion of the rmap file logic which deals with this
traversal from those parts of the logic which interact with the folio.
This patc
Right now the only means by which we can write-protect a range using the
reverse mapping is via folio_mkclean().
However this is not always the appropriate means of doing so, specifically
in the case of the framebuffer deferred I/O logic (fb_defio enabled by
CONFIG_FB_DEFERRED_IO). There, kernel p
in the fb_defio video driver, page dirty state is used to determine when
frame buffer pages have been changed, allowing for batched, deferred I/O to
be performed for efficiency.
This implementation had only one means of doing so effectively - the use of
the folio_mkclean() function.
However, this
Hi Charles,
Thank you for the patch.
On Sat, Feb 08, 2025 at 06:03:22PM +0800, Charles Han wrote:
> devm_kasprintf() can return a NULL pointer on failure,but this
s/but/ but/
> returned value in zynqmp_audio_init() is not checked.
> Add NULL check in zynqmp_audio_init(), to handle kernel NULL
>
On Sat, Feb 08, 2025 at 10:45:41AM +0530, Tejas Vipin wrote:
> Change the visionox-r66451 panel to use multi style functions for
> improved error handling.
>
> Signed-off-by: Tejas Vipin
> ---
> drivers/gpu/drm/panel/panel-visionox-r66451.c | 179 --
> 1 file changed, 76 inserti
Both panels, kingdisplay-kd110n11-51ie and starry-2082109qfh040022-50e,
use the HX83102 IC, so add the compatibility to the hx83102 binding file.
Both kingdisplay-kd110n11-51ie and starry-2082109qfh040022-50e panels use
HX83102 IC, so add these two panels to the driver panel-himax-hx83102.c.
Drop
Add a new compatible for the panels KINGDISPLAY KD110N11-51IE and
STARRY 2082109QFH040022-50E. Both panels use the HX83102 IC, so
add the compatible to the hx83102 bindings file.
Signed-off-by: Langyan Ye
---
.../devicetree/bindings/display/panel/himax,hx83102.yaml | 4
1 file changed,
The starry-2082109qfh040022-50e is a 10.95" TFT panel. The MIPI controller
on this panel is the same as the other panels here, so add this panel to
this driver.
Signed-off-by: Langyan Ye
---
drivers/gpu/drm/panel/panel-himax-hx83102.c | 142
1 file changed, 142 insertions(+)
The kingdisplay-kd110n11-51ie is a 10.95" TFT panel. The MIPI controller
on this panel is the same as the other panels here, so add this panel
to this driver.
Signed-off-by: Langyan Ye
---
drivers/gpu/drm/panel/panel-himax-hx83102.c | 115
1 file changed, 115 insertions(+)
devm_kasprintf() can return a NULL pointer on failure,but this
returned value in zynqmp_audio_init() is not checked.
Add NULL check in zynqmp_audio_init(), to handle kernel NULL
pointer dereference error.
Fixes: 3ec5c1579305 ("drm: xlnx: zynqmp_dpsub: Add DP audio support")
Signed-off-by: Charles
From: Shixiong Ou
Call device_remove_file() when driver remove.
Signed-off-by: Shixiong Ou
---
drivers/video/fbdev/fsl-diu-fb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index 5ac8201c3533..8c91af9a9156 100644
--
From: Shixiong Ou
1. The device_remove_file() need to be called when driver is removing.
2. The device_remove_file() need to be called if the call to
device_create_file() fails.
Signed-off-by: Shixiong Ou
---
v1->v2:
add missing 'return error'.
call device_remove_file() in sh
From: Shixiong Ou
1. The device_remove_file() need to be called when driver is removing.
2. The device_remove_file() need to be called if the call to
device_create_file() fails.
Signed-off-by: Shixiong Ou
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 17 +
1 file changed, 13
On Sat, Feb 08, 2025 at 09:37:56AM +0100, Louis Chauvet wrote:
> On 08/02/25 - 08:12, Greg Kroah-Hartman wrote:
> > On Fri, Feb 07, 2025 at 05:59:04PM +0100, Louis Chauvet wrote:
> > > On 06/02/25 - 18:38, Greg Kroah-Hartman wrote:
> > > > The vkms driver does not need to create a platform device,
On 08/02/25 - 08:12, Greg Kroah-Hartman wrote:
> On Fri, Feb 07, 2025 at 05:59:04PM +0100, Louis Chauvet wrote:
> > On 06/02/25 - 18:38, Greg Kroah-Hartman wrote:
> > > The vkms driver does not need to create a platform device, as there is
> > > no real platform resources associated it, it only di
On 2025/02/08 13:26, Steven Rostedt wrote:
> On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
>>
>> Not sure what the fix is, from a project management perspective the
>> technology industry has never faced a challenge like this. The fork
>> model, which was the classic protection in o
When compiling without CONFIG_IA32_EMULATION, there are some errors:
drivers/accel/amdxdna/amdxdna_mailbox.c: In function ‘mailbox_release_msg’:
drivers/accel/amdxdna/amdxdna_mailbox.c:197:2: error: implicit declaration
of function ‘kfree’.
197 | kfree(mb_msg);
| ^
drivers/accel/amdx
78 matches
Mail list logo
