On some EFI systems, the video BIOS is provided by the EFI firmware. The
boot stub code stores the physical address of the ROM image in pdev->rom.
Currently we attempt to access this pointer using phys_to_virt(), which
doesn't work with CONFIG_HIGHMEM.
On these systems, attempting to load the
On Mon, Mar 16, 2020 at 08:32:12PM +0100, Christoph Hellwig wrote:
> When acting on device private mappings a driver needs to know if the
> device (or other entity in case of kvmppc) actually owns this private
> mapping. This series adds an owner field and converts the migrate_vma
> code over to
On Tue, Mar 17, 2020 at 08:40:58PM -0400, Lyude Paul wrote:
> From: Ville Syrjälä
>
> Add some kind of vblank workers. The interface is similar to regular
> delayed works, and also allows for re-scheduling.
>
> Whatever hardware programming we do in the work must be fast
> (must at least
On Tue, Mar 17, 2020 at 03:43:47PM -0700, Ralph Campbell wrote:
>> Obviously no driver cared for that so far. Once we have test cases
>> for that and thus testable code we can add code to fault it in from
>> hmm_vma_handle_pte.
>>
>
> I'm OK with the series. I think I would have been less
On Tue, Mar 17, 2020 at 09:34:33PM -0400, Mikel Rychliski wrote:
> I think the direct access to pdev->rom you suggest makes sense, especially
> because users of the pci_platform_rom() are exposed to the fact that it just
> calls ioremap().
>
> I decided against wrapping the iounmap() with a
On Tue, Mar 17, 2020 at 08:41:06PM -0400, Lyude Paul wrote:
> + root = debugfs_create_dir("nv_crc", crtc->debugfs_entry);
> + if (IS_ERR(root))
> + return PTR_ERR(root);
No need to check this, just take the return value and move on.
> +
> + dent =
