https://bugzilla.kernel.org/show_bug.cgi?id=209713
Lahfa Samy (s...@lahfa.xyz) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
Hi Linus,
This should be the last round of things for rc1, a bunch of i915
fixes, some amdgpu, more font OOB fixes and one ttm fix just found
reading code.
Dave.
drm-next-2020-10-23:
drm fixes (round two) for 5.10-rc1
fbcon/fonts:
- Two patches to prevent OOB access
ttm:
- fix for eviction val
> On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote:
> >
> > On 2020-05-11 10:12 p.m., Alex Deucher wrote:
> > > On Mon, May 11, 2020 at 1:17 PM Christian König
> > > wrote:
> > >>
> > >> AGP is deprecated for 10+ years now and not used any more on modern
> > >> hardware.
> > >>
> > >> Old har
‐‐‐ Original Message ‐‐‐
On Wednesday, October 21, 2020 2:44 PM, Alex Deucher
wrote:
> On Mon, Oct 19, 2020 at 8:53 PM Josh Fuhs joshua.f...@pm.me wrote:
>
> > Thanks. I tried 5.9.1 and I think there's still a problem, or at least
> > something different.
> > Using the same configuratio
Hi Dave and Daniel,
Here is probably the last drm-intel-next-fixes before -rc1.
This includes a few patches from dinq and a bunch from drm-intel-gt-next.
drm-intel-next-fixes-2020-10-22:
- Tweak initia DPCD backlight.enabled value (Sean)
- Initialize reserved MOCS indices (Ayaz)
- Mark initial f
From: Ville Syrjälä
The new >8k CEA modes have dotclocks reaching 5.94 GHz, which
means our clock*1000 will now overflow the 32bit unsigned
integer. Switch to 64bit maths to avoid it.
Cc: sta...@vger.kernel.org
Reported-by: Randy Dunlap
Signed-off-by: Ville Syrjälä
---
An interesting question
On Thu, Oct 22, 2020 at 7:22 PM Rob Clark wrote:
>
> On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote:
> >
> > On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter
> > wrote:
> > >
> > > The stuff never really worked, and leads to lots of fun because it
> > > out-of-order frees atomic states. Which up
On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
>
> Noticed this when trying to compile with -Wall on a kernel fork. We
> potentially
> don't set width here, which causes the compiler to complain about width
> potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
>
> Signed-o
On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote:
>
> On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter wrote:
> >
> > The stuff never really worked, and leads to lots of fun because it
> > out-of-order frees atomic states. Which upsets KASAN, among other
> > things.
> >
> > For async updates we now
On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter wrote:
>
> The stuff never really worked, and leads to lots of fun because it
> out-of-order frees atomic states. Which upsets KASAN, among other
> things.
>
> For async updates we now have a more solid solution with the
> ->atomic_async_check and ->at
Noticed this when trying to compile with -Wall on a kernel fork. We potentially
don't set width here, which causes the compiler to complain about width
potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
Signed-off-by: Lyude Paul
Cc: # v5.9+
Fixes: 3f649ab728cd ("treewide: R
On Thu, Oct 22, 2020 at 07:07:50PM +0530, Sumera Priyadarsini wrote:
> Using snprintf() for show() methods holds the risk of buffer overrun
> as snprintf() does not know the PAGE_SIZE maximum of the temporary
> buffer used to output sysfs content.
>
> This patchset is a series of Coccinelle cleanu
On Thu, Oct 22, 2020 at 09:36:23AM -0400, Kazlauskas, Nicholas wrote:
> On 2020-10-21 12:32 p.m., Daniel Vetter wrote:
> > The stuff never really worked, and leads to lots of fun because it
> > out-of-order frees atomic states. Which upsets KASAN, among other
> > things.
> >
> > For async updates
On Thu, Oct 22, 2020 at 07:17:56PM +0530, Sumera Priyadarsini wrote:
> Using snprintf() for show() methods holds the risk of buffer overrun
> as snprintf() does not know the PAGE_SIZE maximum of the temporary
> buffer used to output sysfs content.
>
> Modify amdgpu_psp.c to use sysfs_emit() instea
On 2020-10-21 12:32 p.m., Daniel Vetter wrote:
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit
On Tue, Oct 20, 2020 at 01:57:11PM +0200, Guido Günther wrote:
> Hi Daniel, Sam,
> On Mon, Oct 19, 2020 at 05:44:37PM +0200, Daniel Vetter wrote:
> > On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > > Hi Guido.
> > >
> > > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wr
On Thu, Oct 22, 2020 at 1:43 PM Jason Gunthorpe wrote:
>
> On Thu, Oct 22, 2020 at 09:00:44AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 22, 2020 at 1:20 AM Jason Gunthorpe wrote:
> > >
> > > On Wed, Oct 21, 2020 at 09:24:08PM +0200, Daniel Vetter wrote:
> > > > On Wed, Oct 21, 2020 at 6:37 PM J
Hi,
On 10/22/20 12:57 PM, Thomas Zimmermann wrote:
> Hi Hans
>
> On 22.10.20 12:17, Hans de Goede wrote:
>> Hi,
>>
>> On 10/22/20 11:30 AM, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> On 22.10.20 11:20, Hans de Goede wrote:
Hi,
On 10/21/20 3:07 PM, Thomas Zimmermann wrote:
> The dr
Hi Hans
On 22.10.20 12:17, Hans de Goede wrote:
> Hi,
>
> On 10/22/20 11:30 AM, Thomas Zimmermann wrote:
>> Hi
>>
>> On 22.10.20 11:20, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 10/21/20 3:07 PM, Thomas Zimmermann wrote:
The drivers gm12u320 and udl operate on USB devices. They leave the
On Thu, Oct 22, 2020 at 10:34:44AM +, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (bec
On Wed, Oct 21, 2020 at 10:01:45PM -0700, Abhinav Kumar wrote:
> Currently drm_atomic_print_state() internally allocates and uses a
> drm_info printer. Allow it to accept any drm_printer type so that
> the API can be leveraged even for taking drm snapshot.
>
> Signed-off-by: Abhinav Kumar
> ---
>
On Friday, October 9, 2020 12:25 PM, Brian Starkey
wrote:
> I assume that this is so that the kernel can apply quirks/limits in
> cases where it knows it needs to? I think it would be nice to put at
> least a few words indicating "why", otherwise this feels like an
> arbitrary commandment with n
User-space should avoid parsing EDIDs for metadata already exposed via
other KMS interfaces and properties. For instance, user-space should not
try to extract a list of modes from the EDID: the kernel might mutate
the mode list (because of link capabilities or quirks for instance).
Other metadata
On Thu, Oct 22, 2020 at 11:18 AM Thomas Zimmermann wrote:
>
> Hi
>
> On 22.10.20 10:49, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
> >> Kernel DRM clients now store their framebuffer address in an instance
> >> of struct dma_buf_map. Depending on th
Hi,
On 10/22/20 11:30 AM, Thomas Zimmermann wrote:
> Hi
>
> On 22.10.20 11:20, Hans de Goede wrote:
>> Hi,
>>
>> On 10/21/20 3:07 PM, Thomas Zimmermann wrote:
>>> The drivers gm12u320 and udl operate on USB devices. They leave the
>>> PCI device in struct drm_device empty and store the USB device
On Wed, Oct 21, 2020 at 08:13:43PM -0700, Randy Dunlap wrote:
> Hi,
>
> With linux-next 20201021, when booting up, I am seeing this:
>
> [0.560896] UBSAN: signed-integer-overflow in
> ../drivers/gpu/drm/drm_modes.c:765:20
> [0.560903] 2376000 * 1000 cannot be represented in type 'int'
D
Hi Abhinav,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.9 next-20201022]
[cannot apply to drm/drm-next]
[If your
Thanks for this!
I can't review the correctness, but the description looks clear to me
so,
Reviewed-by: Jonas Ådahl
Jonas
On Thu, Oct 22, 2020 at 09:38:05AM +, Simon Ser wrote:
> User-space doesn't need to keep track of blobs that might be in use by
> the kernel. User-space can just destr
User-space doesn't need to keep track of blobs that might be in use by
the kernel. User-space can just destroy blobs as soon as they don't need
them anymore.
Signed-off-by: Simon Ser
Cc: Pekka Paalanen
Cc: Daniel Vetter
Cc: Jonas Ådahl
---
include/uapi/drm/drm_mode.h | 4
1 file changed,
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
v2:
Init the hdcp port data k for HDMI/DP SST strem.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/dri
This requires for HDCP 2.2 MST check link.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/d
Enable HDCP 2.2 over DP MST.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 46 ++-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 4 +
drivers/gpu/drm/i915/d
v3 version of this series has fixed the CI reported failures
and added below patch in this series.
[PATCH v3 02/16] drm/i915/hdcp: Get conn while content_type changed
It has also added the Ack of Tomas to merge the mei_hdcp.c patch
via drm-intel.
This series has been tested with IGT changes to d
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving th
Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.
Cc: Sean Paul
Cc: Ramalingam C
Acked-by: Maarten Lankhorst
Signed-off-by: Anshuman Gupta
---
include/drm/drm_hdcp.h | 8
1 file changed, 4 insertions(+), 4 deletions(
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_hdcp.c| 12 +++---
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +
.../drm
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
update_pipe instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actually hdcp->value was ENABLED.
T
Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.
v2:
hdcp_cmd_header size annotation nitpick. [Tomas]
Cc: Tomas Winkler
Cc: Ramalingam C
Ack
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä"
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
1 file
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing
connectors")
Cc: Sean Paul
Cc: Ramalingam C
Signed-off-by: Anshuman Gu
Enable HDCP 1.4 over DP MST for Gen12.
This also enable the stream encryption support for
older generations, which was missing earlier.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gup
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used
Hi
On 22.10.20 11:20, Hans de Goede wrote:
> Hi,
>
> On 10/21/20 3:07 PM, Thomas Zimmermann wrote:
>> The drivers gm12u320 and udl operate on USB devices. They leave the
>> PCI device in struct drm_device empty and store the USB device in their
>> own driver structure.
>>
>> Fix this special case
Hi,
On 10/21/20 3:07 PM, Thomas Zimmermann wrote:
> The drivers gm12u320 and udl operate on USB devices. They leave the
> PCI device in struct drm_device empty and store the USB device in their
> own driver structure.
>
> Fix this special case and save a few bytes by putting the USB device
> into
Hi
On 22.10.20 10:49, Daniel Vetter wrote:
> On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
>> Kernel DRM clients now store their framebuffer address in an instance
>> of struct dma_buf_map. Depending on the buffer's location, the address
>> refers to system or I/O memory.
>>
>
On Thu, Oct 22, 2020 at 10:37:56AM +0200, Thomas Zimmermann wrote:
> Hi
>
> On 22.10.20 10:05, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> >> At least sparc64 requires I/O-specific access to framebuffers. This
> >> patch updates the fbdev console a
On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
> Kernel DRM clients now store their framebuffer address in an instance
> of struct dma_buf_map. Depending on the buffer's location, the address
> refers to system or I/O memory.
>
> Callers of drm_client_buffer_vmap() receive a co
Hi
On 22.10.20 10:05, Daniel Vetter wrote:
> On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
>> At least sparc64 requires I/O-specific access to framebuffers. This
>> patch updates the fbdev console accordingly.
>>
>> For drivers with direct access to the framebuffer memory, the
Hi Abhinav,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.9 next-20201022]
[cannot apply to drm/drm-next]
[If your
Am 22.10.20 um 05:11 schrieb Dave Airlie:
From: Dave Airlie
remove the overlapping memcp support as it's never used.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for t
On Wed, Oct 21, 2020 at 09:55:57AM +0200, Niklas Schnelle wrote:
> Hi Daniel,
>
> friendly ping. I haven't seen a new version of this patch series,
> as I said I think your change for s390/pci is generally useful so
> I'm curious, are you planning on sending a new version soon?
> If you want you c
On Wed, 21 Oct 2020 18:09:05 +0100
Daniel Stone wrote:
> On Wed, 21 Oct 2020 at 17:34, Daniel Vetter wrote:
> > On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote:
> > > It makes sense to me: some modes are annotated with a 'low-power'
> > > flag, tucked away behind a client cap whic
Hi
On 22.10.20 01:57, saeed.mirzamohamm...@oracle.com wrote:
> From: Saeed Mirzamohammadi
>
> This patch fixes the issue due to:
>
> [ 89.572883] divide_error: [#1] SMP KASAN PTI
> [ 89.572897] CPU: 3 PID: 16083 Comm: repro Not tainted
> 5.9.0-rc7.20200930.rc1.allarch-19-g3e32d0d.syzk
Hi
On 22.10.20 01:57, saeed.mirzamohamm...@oracle.com wrote:
> From: Saeed Mirzamohammadi
>
> This patch fixes the issue due to:
>
> [ 89.572883] divide_error: [#1] SMP KASAN PTI
> [ 89.572897] CPU: 3 PID: 16083 Comm: repro Not tainted
> 5.9.0-rc7.20200930.rc1.allarch-19-g3e32d0d.syzk
On 10/21/20 10:56 AM, Daniel Vetter wrote:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with unmap_mapping_range when buffers get mo
On Wed, Oct 21, 2020 at 09:24:08PM +0200, Daniel Vetter wrote:
> On Wed, Oct 21, 2020 at 6:37 PM Jason Gunthorpe wrote:
> >
> > On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wrote:
> >
> > > The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to
> > > split that. So ideally
On Wed, 14 Oct 2020 at 23:55, Geert Uytterhoeven wrote:
>
> Hi Alexandru,
>
> On Tue, Oct 13, 2020 at 1:57 PM Alexandru Stan wrote:
> > Whenever num-interpolated-steps was larger than the distance
> > between 2 consecutive brightness levels the table would get really
> > discontinuous. The slope
Hi Daniel,
friendly ping. I haven't seen a new version of this patch series,
as I said I think your change for s390/pci is generally useful so
I'm curious, are you planning on sending a new version soon?
If you want you can also just sent this patch with the last few
nitpicks (primarily the mail a
On 05-10-20, 11:56, Viresh Kumar wrote:
> On 28-08-20, 11:37, Viresh Kumar wrote:
> > dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> > find the OPP table with error -ENODEV (i.e. OPP table not present for
> > the device). And we can call dev_pm_opp_of_remove_table()
> > u
On Wed, Oct 21, 2020 at 10:56:39AM +0200, Daniel Vetter wrote:
> Hi all,
>
> Round 3 of my patch series to clamp down a bunch of races and gaps
> around follow_pfn and other access to iomem mmaps. Previous version:
>
> v1:
> https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet..
On Wed, Oct 21, 2020 at 10:56:51AM +0200, Daniel Vetter wrote:
> There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> files, and the old proc interface. Two check against
> iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
> this starts to matter, since we don
On Wed, Oct 21, 2020 at 04:42:11PM +0200, Daniel Vetter wrote:
> Uh yes. In drivers/gpu this isn't a problem because we only install
> ptes from the vm_ops->fault handler. So no races. And I don't think
> you can fix this otherwise through holding locks: mmap_sem we can't
> hold because before vma
I was trying to adjust the brightness-levels for the trogdor boards:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209
Like on a lot of panels, trogdor's low end needs to be cropped,
and now that we have the interpolation stuff I wanted to make use of it
and bake in
On 21-10-20, 09:58, Rob Clark wrote:
> On Wed, Oct 21, 2020 at 12:24 AM Viresh Kumar wrote:
> >
> > On 05-10-20, 11:56, Viresh Kumar wrote:
> > > On 28-08-20, 11:37, Viresh Kumar wrote:
> > > > dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> > > > find the OPP table with
Hi!
Dne četrtek, 15. oktober 2020 ob 11:36:41 CEST je Maxime Ripard napisal(a):
> When using the scaler on the A10-like frontend with single-planar formats,
> the current code will setup the channel 0 filter (used for the R or Y
> component) with a different phase parameter than the channel 1 filt
Hi!
Dne četrtek, 15. oktober 2020 ob 11:36:40 CEST je Maxime Ripard napisal(a):
> The scaler filter phase setup in the allwinner kernel has two different
> cases for setting up the scaler filter, the first one using different phase
> parameters for the two channels, and the second one reusing the
Hi,
With linux-next 20201021, when booting up, I am seeing this:
[0.560896] UBSAN: signed-integer-overflow in
../drivers/gpu/drm/drm_modes.c:765:20
[0.560903] 2376000 * 1000 cannot be represented in type 'int'
[0.560909] CPU: 3 PID: 7 Comm: kworker/u16:0 Not tainted
5.9.0-next-20201
On 28-08-20, 11:37, Viresh Kumar wrote:
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can call dev_pm_opp_of_remove_table()
> unconditionally here.
>
> Reviewed-by: Qiang Yu
>
From: Saeed Mirzamohammadi
This patch fixes the issue due to:
[ 89.572883] divide_error: [#1] SMP KASAN PTI
[ 89.572897] CPU: 3 PID: 16083 Comm: repro Not tainted
5.9.0-rc7.20200930.rc1.allarch-19-g3e32d0d.syzk #5
[ 89.572902] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BI
On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wrote:
> The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to
> split that. So ideally ->mmap would never set up any ptes.
/dev/mem makes pgoff == pfn so it doesn't get changed by remap.
pgoff doesn't get touched for MAP_SHAR
Hi Chun-Kuang,
On Wed, Oct 21, 2020 at 7:01 PM Chun-Kuang Hu wrote:
>
> Hi, Fabien:
>
> Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
> >
> > Add binding documentation for the MT8167 SoC. The SoC needs
> > an additional clock compared to the already supported SoC: mipi26m.
> >
> > Signed-off-by: Fabi
Hi!
Dne četrtek, 15. oktober 2020 ob 11:36:42 CEST je Maxime Ripard napisal(a):
> The A33 has a different phase parameter in the Allwinner BSP on the
> channel1 than the one currently applied. Fix this.
>
> Signed-off-by: Maxime Ripard
Acked-by: Jernej Skrabec
Best regards,
Jernej
_
- atomic_check removed
- video data input and output formats added
- bus formats read from drm_bridge_state.output_bus_cfg.format
and .atomic_get_input_bus_fmts() instead of connector
Signed-off-by: Vinay Simha BN
---
v1:
* Laurent Pinchart review comments incorporated
drm_bridge_state.out
Return statements for functions returning bool should use truth
and false instead of 1 and 0 respectively.
Modify cik_event_interrupt.c to return false instead of 0.
Issue found with Coccinelle.
Signed-off-by: Sumera Priyadarsini
---
drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c | 4 ++--
1
Hello,
syzbot found the following issue on:
HEAD commit:c4d6fe73 Merge tag 'xarray-5.9' of git://git.infradead.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14862ff050
kernel config: https://syzkaller.appspot.com/x/.config?x=7d790573d3e379c4
das
Attached the Syzkaller C reproducer.
repro.c
Description: Binary data
> On Oct 21, 2020, at 4:57 PM, saeed.mirzamohamm...@oracle.com wrote:
>
> From: Saeed Mirzamohammadi
>
> This patch fixes the issue due to:
>
> [ 89.572883] divide_error: [#1] SMP KASAN PTI
> [ 89.572897] CPU: 3
20.10.2020 12:18, Mikko Perttunen пишет:
>> I'm asking this question because right now there is only one potential
>> client for this IOCTL, the VIC. If other clients aren't supposed to be a
>> part of the DRM driver, like for example NVDEC which probably should be
>> a V4L driver, then DRM driver
The previous behavior was a little unexpected, its properties/problems:
1. It was designed to generate strictly increasing values (no repeats)
2. It had quantization errors when calculating step size. Resulting in
unexpected jumps near the end of some segments.
Example settings:
brightness
Hi
On 22.10.20 01:06, Laurent Pinchart wrote:
> Hi Thomas,
>
> Thank you for the patch.
>
> On Wed, Oct 21, 2020 at 02:12:41PM +0200, Thomas Zimmermann wrote:
>> Trying to copy into the string fields with strncpy() gives a warning from
>> gcc. Both fields are part of a packed HDMI header and do
On Thu, Oct 22, 2020 at 1:20 AM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 09:24:08PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 21, 2020 at 6:37 PM Jason Gunthorpe wrote:
> > >
> > > On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wrote:
> > >
> > > > The trouble is that io_rema
85 matches
Mail list logo
