Hi, Christoph,
On Mon, 2019-04-22 at 19:56 +0200, h...@lst.de wrote:
> On Wed, Apr 10, 2019 at 03:01:14PM +, Thomas Hellstrom wrote:
> > > So can you please respin a version acceptable to you and submit
> > > it
> > > for 5.1 ASAP? Otherwise I'll need to move ahead with the simple
> > >
On Wed, Apr 10, 2019 at 03:01:14PM +, Thomas Hellstrom wrote:
> > So can you please respin a version acceptable to you and submit it
> > for 5.1 ASAP? Otherwise I'll need to move ahead with the simple
> > revert.
>
> I will.
> I need to do some testing to investigate how to best choose
On Wed, 2019-04-10 at 08:43 +0200, h...@lst.de wrote:
> On Tue, Apr 09, 2019 at 05:24:48PM +, Thomas Hellstrom wrote:
> > > Note that this only affects external, untrusted devices. But
> > > that
> > > may include eGPU,
> >
> > What about discrete graphics cards, like Radeon and Nvidia? Who
On Tue, Apr 09, 2019 at 05:24:48PM +, Thomas Hellstrom wrote:
> > Note that this only affects external, untrusted devices. But that
> > may include eGPU,
>
> What about discrete graphics cards, like Radeon and Nvidia? Who gets to
> determine what's trusted?
Based on firmware tables.
On Tue, 2019-04-09 at 17:25 +0200, h...@lst.de wrote:
> On Tue, Apr 09, 2019 at 02:17:40PM +, Thomas Hellstrom wrote:
> > If that's the case, I think most of the graphics drivers will stop
> > functioning. I don't think people would want that, and even if the
> > graphics drivers are "to
On Tue, Apr 09, 2019 at 02:17:40PM +, Thomas Hellstrom wrote:
> If that's the case, I think most of the graphics drivers will stop
> functioning. I don't think people would want that, and even if the
> graphics drivers are "to blame" due to not implementing the sync calls,
> I think the work
On Tue, 2019-04-09 at 15:31 +0200, h...@lst.de wrote:
> On Tue, Apr 09, 2019 at 01:04:51PM +, Thomas Hellstrom wrote:
> > On the VMware platform we have two possible vIOMMUS, the AMD iommu
> > and
> > Intel VTD, Given those conditions I belive the patch is
> > functionally
> > correct. We
On Tue, Apr 09, 2019 at 01:04:51PM +, Thomas Hellstrom wrote:
> On the VMware platform we have two possible vIOMMUS, the AMD iommu and
> Intel VTD, Given those conditions I belive the patch is functionally
> correct. We can't cover the AMD case with intel_iommu_enabled.
> Furthermore the only
On Tue, 2019-04-09 at 11:57 +0200, h...@lst.de wrote:
> On Mon, Apr 08, 2019 at 06:47:52PM +, Thomas Hellstrom wrote:
> > We HAVE discussed our needs, although admittedly some of my emails
> > ended up unanswered.
>
> And than you haven't followed up, and instead ignored the layering
>
On Mon, Apr 08, 2019 at 06:47:52PM +, Thomas Hellstrom wrote:
> We HAVE discussed our needs, although admittedly some of my emails
> ended up unanswered.
And than you haven't followed up, and instead ignored the layering
instructions and just commited a broken patch?
> We've as you're well
Christoph,
On Mon, 2019-04-08 at 12:55 +0200, Christoph Hellwig wrote:
> Hi Linus,
>
> unfortunately it took less than a merge window for the:
>
> /*
> * All the dma_direct_* declarations are here just for the indirect
> call bypass,
> * and must not be used directly drivers!
> */
>
>
Hi Linus,
unfortunately it took less than a merge window for the:
/*
* All the dma_direct_* declarations are here just for the indirect call bypass,
* and must not be used directly drivers!
*/
warning in dma-mapping.h to be ignored. This series reverts the offender
to keep our API clean.
12 matches
Mail list logo
