[PATCH v5 6/6] srcu: Document srcu_flip() memory-barrier D relation to SRCU-fast

omitting it in the SRCU-fast case. So the same code +* is executed either way. */ smp_mb(); /* D */ /* Pairs with C. */ } -- 2.40.1

[PATCH v4 6/6] srcu: Document srcu_flip() memory-barrier D relation to SRCU-fast

omitting it in the SRCU-fast case. So the same code +* is executed either way. */ smp_mb(); /* D */ /* Pairs with C. */ } -- 2.40.1

[PATCH v3 6/4] srcu: Document srcu_flip() memory-barrier D relation to SRCU-fast

either way. */ smp_mb(); /* D */ /* Pairs with C. */ }

Re: [PATCH 0/2] Some small preparations around CAMSS D-PHY / C-PHY support

On 17/03/2025 07:45, Luca Weiss wrote: On Wed Feb 26, 2025 at 3:47 PM CET, Bryan O'Donoghue wrote: On 26/02/2025 14:13, Luca Weiss wrote: Hi all, On Mon Dec 9, 2024 at 1:01 PM CET, Luca Weiss wrote: Since the hardware blocks on the SoCs generally support both D-PHY and C-PHY standard

Re: [PATCH 0/2] Some small preparations around CAMSS D-PHY / C-PHY support

On Wed Feb 26, 2025 at 3:47 PM CET, Bryan O'Donoghue wrote: > On 26/02/2025 14:13, Luca Weiss wrote: >> Hi all, >> >> On Mon Dec 9, 2024 at 1:01 PM CET, Luca Weiss wrote: >>> Since the hardware blocks on the SoCs generally support both D-PHY and >>&g

Re: [PATCH 0/2] Some small preparations around CAMSS D-PHY / C-PHY support

On 26/02/2025 14:13, Luca Weiss wrote: Hi all, On Mon Dec 9, 2024 at 1:01 PM CET, Luca Weiss wrote: Since the hardware blocks on the SoCs generally support both D-PHY and C-PHY standards for camera, but the camss driver currently is only supporting D-PHY, do some preparations in order to add C

Re: [PATCH 0/2] Some small preparations around CAMSS D-PHY / C-PHY support

Hi all, On Mon Dec 9, 2024 at 1:01 PM CET, Luca Weiss wrote: > Since the hardware blocks on the SoCs generally support both D-PHY and > C-PHY standards for camera, but the camss driver currently is only > supporting D-PHY, do some preparations in order to add C-PHY support at >

Re: [PATCH 2/2] media: qcom: camss: Restrict endpoint bus-type to D-PHY

Hi Luca. On 12/9/24 14:01, Luca Weiss wrote: Currently the Qualcomm CAMSS driver only supports D-PHY while the hardware on most SoCs also supports C-PHY. Until this support is added, check for D-PHY to make it somewhat explicit that C-PHY won't work. Signed-off-by: Luca Weiss --- dr

Re: [PATCH 2/2] media: qcom: camss: Restrict endpoint bus-type to D-PHY

On 12/13/24 13:22, Luca Weiss wrote: On Fri Dec 13, 2024 at 12:02 PM CET, Vladimir Zapolskiy wrote: On 12/9/24 14:32, Bryan O'Donoghue wrote: On 09/12/2024 12:01, Luca Weiss wrote: Currently the Qualcomm CAMSS driver only supports D-PHY while the hardware on most SoCs also supports

Re: [PATCH 2/2] media: qcom: camss: Restrict endpoint bus-type to D-PHY

On Fri Dec 13, 2024 at 12:02 PM CET, Vladimir Zapolskiy wrote: > On 12/9/24 14:32, Bryan O'Donoghue wrote: > > On 09/12/2024 12:01, Luca Weiss wrote: > >> Currently the Qualcomm CAMSS driver only supports D-PHY while the > >> hardware on most SoCs also supports C-

Re: [PATCH 2/2] media: qcom: camss: Restrict endpoint bus-type to D-PHY

On 12/9/24 14:32, Bryan O'Donoghue wrote: On 09/12/2024 12:01, Luca Weiss wrote: Currently the Qualcomm CAMSS driver only supports D-PHY while the hardware on most SoCs also supports C-PHY. Until this support is added, check for D-PHY to make it somewhat explicit that C-PHY won't wor

Re: [PATCH 2/2] media: qcom: camss: Restrict endpoint bus-type to D-PHY

On 09/12/2024 12:01, Luca Weiss wrote: Currently the Qualcomm CAMSS driver only supports D-PHY while the hardware on most SoCs also supports C-PHY. Until this support is added, check for D-PHY to make it somewhat explicit that C-PHY won't work. Signed-off-by: Luca Weiss --- drivers/

[PATCH 2/2] media: qcom: camss: Restrict endpoint bus-type to D-PHY

Currently the Qualcomm CAMSS driver only supports D-PHY while the hardware on most SoCs also supports C-PHY. Until this support is added, check for D-PHY to make it somewhat explicit that C-PHY won't work. Signed-off-by: Luca Weiss --- drivers/media/platform/qcom/camss/camss.c | 9 +++

[PATCH 0/2] Some small preparations around CAMSS D-PHY / C-PHY support

Since the hardware blocks on the SoCs generally support both D-PHY and C-PHY standards for camera, but the camss driver currently is only supporting D-PHY, do some preparations in order to add C-PHY support at some point. Make the dt bindings explicit that the hardware supports both (except for

[PATCH AUTOSEL 4.19 5/8] virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings

From: Zhu Yanjun [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ] Fix the warnings when building virtio_net driver. " drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of si

[PATCH AUTOSEL 5.4 08/11] virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings

From: Zhu Yanjun [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ] Fix the warnings when building virtio_net driver. " drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of si

[PATCH AUTOSEL 5.10 09/13] virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings

From: Zhu Yanjun [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ] Fix the warnings when building virtio_net driver. " drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of si

[PATCH AUTOSEL 5.15 14/19] virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings

From: Zhu Yanjun [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ] Fix the warnings when building virtio_net driver. " drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of si

[PATCH AUTOSEL 6.1 18/27] virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings

From: Zhu Yanjun [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ] Fix the warnings when building virtio_net driver. " drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of si

[PATCH AUTOSEL 6.6 21/31] virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings

From: Zhu Yanjun [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ] Fix the warnings when building virtio_net driver. " drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of si

[PATCH AUTOSEL 6.7 29/39] virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings

From: Zhu Yanjun [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ] Fix the warnings when building virtio_net driver. " drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of si

Re: [PATCH v2 2/2] MAINTAINERS: migrate some K to D

On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote: > Let's get the ball rolling with some changes from K to D. > > Ultimately, if it turns out that 100% of K users want to change to D > then really the behavior of K could just be changed. Given my suggestion to 1/2, this wou

[PATCH v2 2/2] MAINTAINERS: migrate some K to D

Let's get the ball rolling with some changes from K to D. Ultimately, if it turns out that 100% of K users want to change to D then really the behavior of K could just be changed. Signed-off-by: Justin Stitt Original-author: Kees Cook --- MAINTAINERS | 16 +--- 1 file chang

Re: [PATCH 1/3] MAINTAINERS: add documentation for D:

On Wed, Sep 27, 2023 at 03:19:14AM +, Justin Stitt wrote: > Document what "D:" does. > > This is more or less the same as what "K:" does but only works for patch > files. > > See [3/3] for more info and an illustrative example. > --- > MAINTAI

Re: [PATCH 1/3] MAINTAINERS: add documentation for D:

On Wed, 2023-09-27 at 03:19 +, Justin Stitt wrote: > Document what "D:" does. > > This is more or less the same as what "K:" does but only works for patch > files. Nack. I'd rather just add a !$file test to K: patterns.

[PATCH 1/3] MAINTAINERS: add documentation for D:

Document what "D:" does. This is more or less the same as what "K:" does but only works for patch files. See [3/3] for more info and an illustrative example. --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b19995690904.

Re: [PATCH 1/3] MAINTAINERS: add documentation for D:

On Wed, Sep 27, 2023 at 12:27 PM Joe Perches wrote: > > On Wed, 2023-09-27 at 03:19 +, Justin Stitt wrote: > > Document what "D:" does. > > > > This is more or less the same as what "K:" does but only works for patch > > files. > > Nack.

Re: [PATCH] docs: fix the invalid vt-d spec location

On Mon, Apr 19, 2021 at 04:05:12PM +0800, Steven Zhou wrote: > Do you have any other suggestion about the link location please ? Yeah, I'm working on it. We need to come up with a proper solution for all those docs but it'll take time... Thx. -- Regards/Gruss, Boris. https://people.kernel.

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 11:02 AM Sakari Ailus wrote: > > Hi Bingbu, > > Thanks for the patch. > > On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote: > > Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, > > The IPU driver allocates its own page table that is not mapped > > vi

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 05:54:57PM +0300, Andy Shevchenko wrote: > On Tue, Apr 20, 2021 at 05:37:27PM +0300, Sakari Ailus wrote: > > On Tue, Apr 20, 2021 at 02:55:33PM +0300, Andy Shevchenko wrote: > > > On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote: > > > > On Tue, Apr 20, 2021 at 0

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 05:37:27PM +0300, Sakari Ailus wrote: > On Tue, Apr 20, 2021 at 02:55:33PM +0300, Andy Shevchenko wrote: > > On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote: > > > On Tue, Apr 20, 2021 at 06:34:26PM +0800, Bingbu Cao wrote: > > > > On 4/20/21 6:20 PM, Andy Shevc

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 02:55:33PM +0300, Andy Shevchenko wrote: > On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote: > > On Tue, Apr 20, 2021 at 06:34:26PM +0800, Bingbu Cao wrote: > > > On 4/20/21 6:20 PM, Andy Shevchenko wrote: > > > > On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote: > On Tue, Apr 20, 2021 at 06:34:26PM +0800, Bingbu Cao wrote: > > On 4/20/21 6:20 PM, Andy Shevchenko wrote: > > > On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote: ... > > > This misses the changelog from v1 followed by the

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

Hi Bingbu, Thanks for the patch. On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote: > Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, > The IPU driver allocates its own page table that is not mapped > via the DMA, and thus the Intel IOMMU driver blocks access giving > this

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

Hi Bingbu, On Tue, Apr 20, 2021 at 06:34:26PM +0800, Bingbu Cao wrote: > Andy, > > On 4/20/21 6:20 PM, Andy Shevchenko wrote: > > On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote: > >> Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, > >> The IPU driver allocates its own p

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

Andy, On 4/20/21 6:20 PM, Andy Shevchenko wrote: > On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote: >> Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, >> The IPU driver allocates its own page table that is not mapped >> via the DMA, and thus the Intel IOMMU driver blocks

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote: > Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, > The IPU driver allocates its own page table that is not mapped > via the DMA, and thus the Intel IOMMU driver blocks access giving > this error: > > DMAR: DRHD: handling f

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote: > Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, > The IPU driver allocates its own page table that is not mapped > via the DMA, and thus the Intel IOMMU driver blocks access giving > this error: > > DMAR: DRHD: handling f

[RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, The IPU driver allocates its own page table that is not mapped via the DMA, and thus the Intel IOMMU driver blocks access giving this error: DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Read] Request device [00:05.0] PASID ff

[PATCH v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, The IPU driver allocates its own page table that is not mapped via the DMA, and thus the Intel IOMMU driver blocks access giving this error: DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Read] Request device [00:05.0] PASID ff

Re: [PATCH] docs: fix the invalid vt-d spec location

Hi Boris, Thank you for your comments. The vt-d spec PDF is around 11M size and after be zipped it's still around 10M size which cannot be uploaded to "bugzilla.kernel.org" because this site limits 5M file size to be uploaded. Seems currently I cannot use the similar way as what y

Re: [PATCH] docs: fix the invalid vt-d spec location

On Sun, Apr 18, 2021 at 09:29:46AM -0700, Liang Zhou wrote: > This patch fixes the invalid vt-d spec location. Avoid having "This patch" or "This commit" in the commit message. It is tautologically useless. Also, do $ git grep 'This patch' Documentation/process

[PATCH] docs: fix the invalid vt-d spec location

This patch fixes the invalid vt-d spec location. Signed-off-by: Liang Zhou --- Documentation/x86/intel-iommu.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst index 099f13d..e95ee34 100644 --- a

Re: [PATCH v2] iommu/vt-d: Force to flush iotlb before creating superpage

On Thu, Apr 15, 2021 at 08:46:28AM +0800, Longpeng(Mike) wrote: > Fixes: 6491d4d02893 ("intel-iommu: Free old page tables before creating > superpage") > Cc: # v3.0+ > Link: > https://lore.kernel.org/linux-iommu/670baaf8-4ff8-4e84-4be3-030b95ab5...@huawei.com/ > Suggested-by: Lu Baolu > Signed-

Re: [PATCH] iommu/vt-d: Fix an error handling path in 'intel_prepare_irq_remapping()'

On Sun, Apr 11, 2021 at 09:08:17AM +0200, Christophe JAILLET wrote: > drivers/iommu/intel/irq_remapping.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks.

Re: [PATCH 1/1] iommu/vt-d: Fix build error of pasid_enable_wpe() with !X86

On Sun, Apr 11, 2021 at 02:23:12PM +0800, Lu Baolu wrote: > drivers/iommu/intel/pasid.c | 2 ++ > 1 file changed, 2 insertions(+) Applied, thanks.

[PATCH v5 2/6] KVM: arm64: Move D-cache flush to the fault handlers

We currently uniformly permorm CMOs of D-cache and I-cache in function user_mem_abort before calling the fault handlers. If we get concurrent guest faults(e.g. translation faults, permission faults) or some really unnecessary guest faults caused by BBM, CMOs for the first vcpu are necessary while

Re: [PATCH v2] iommu/vt-d: Force to flush iotlb before creating superpage

(b)DMA UNMAP 0,0xa (c)DMA MAP 0,0xc000 * DMA read IOVA 0 may failure here (Not present) * if the problem occurs. (d)DMA UNMAP 0,0xc000 } The page table(only focus on IOVA 0) after (a) is: PML4: 0x19db5c1003 entry

[PATCH v2] iommu/vt-d: Force to flush iotlb before creating superpage

0,0xc000 * DMA read IOVA 0 may failure here (Not present) * if the problem occurs. (d)DMA UNMAP 0,0xc000 } The page table(only focus on IOVA 0) after (a) is: PML4: 0x19db5c1003 entry:0x899bdcd2f000 PDPE: 0x1a1cacb003 entry:0x89b35b5c1000 PDE

[PATCH v2][next] iommu/vt-d: Fix out-bounds-warning in intel_svm_page_response()

ommu/intel/svm.c +++ b/drivers/iommu/intel/svm.c @@ -1020,9 +1020,10 @@ static irqreturn_t prq_event_thread(int irq, void *d) resp.qw2 = 0; resp.qw3 = 0; - if (req->priv_data_present) -

Re: [PATCH][next] iommu/vt-d: Fix out-bounds-warning in intel_svm_page_response()

Hi Balou, On 4/14/21 00:24, Lu Baolu wrote: > Hi Gustavo, > > On 4/14/21 3:54 AM, Gustavo A. R. Silva wrote: >> Replace call to memcpy() with just a couple of simple assignments in >> order to fix the following out-of-bounds warning: >> >> drivers/iommu/intel/svm.c:1198:4: warning: 'memcpy' offse

Re: Bug#986561: linux: Regression in drivers/hid/hid-dr.c causing horizontal D-pad to malfunction on SNES joystick

], using a gamepad identified as "DragonRise" with USB ID 0079:0011. The joypad works as intended except for the D-pad: up and down are detected in jstest (though misinterpreted: the input graph shows the points in the left up/down corners instead of the center), the left and right b

Re: Bug#986561: linux: Regression in drivers/hid/hid-dr.c causing horizontal D-pad to malfunction on SNES joystick

; identified as "DragonRise" with USB ID 0079:0011. > > The joypad works as intended except for the D-pad: up and down are detected > in jstest (though misinterpreted: the input graph shows the points in the > left up/down corners instead of the center), the left and right butto

Re: [PATCH 5.4 v3 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

On Mon, Apr 12, 2021 at 01:27:35PM -0700, Saeed Mirzamohammadi wrote: > The IOMMU driver calculates the guest addressability for a DMA request > based on the value of the mgaw reported from the IOMMU. However, this > is a fused value and as mentioned in the spec, the guest width > should be calcula

Re: [PATCH 5.4 v3 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

On Tue, Apr 13, 2021 at 11:05:34AM -0700, Saeed Mirzamohammadi wrote: > Hi Greg, > > I don’t have any commit ID since the fix is not in mainline or any Linus’ > tree yet. The driver has completely changed for newer stable versions (and > also mainline) and the fix only applies for 5.4, 4.19, and

Re: [PATCH][next] iommu/vt-d: Fix out-bounds-warning in intel_svm_page_response()

Hi Gustavo, On 4/14/21 3:54 AM, Gustavo A. R. Silva wrote: Replace call to memcpy() with just a couple of simple assignments in order to fix the following out-of-bounds warning: drivers/iommu/intel/svm.c:1198:4: warning: 'memcpy' offset [25, 32] from the object at 'desc' is out of the bounds o

[PATCH][next] iommu/vt-d: Fix out-bounds-warning in intel_svm_page_response()

Replace call to memcpy() with just a couple of simple assignments in order to fix the following out-of-bounds warning: drivers/iommu/intel/svm.c:1198:4: warning: 'memcpy' offset [25, 32] from the object at 'desc' is out of the bounds of referenced subobject 'qw2' with type 'long long unsigned in

Re: [PATCH 5.4 v3 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

Hi Greg, I don’t have any commit ID since the fix is not in mainline or any Linus’ tree yet. The driver has completely changed for newer stable versions (and also mainline) and the fix only applies for 5.4, 4.19, and 4.14 stable kernels. Thanks, Saeed > On Apr 13, 2021, at 12:32 AM, Greg KH

Re: [PATCH 5.4 v3 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

On Mon, Apr 12, 2021 at 01:27:35PM -0700, Saeed Mirzamohammadi wrote: > The IOMMU driver calculates the guest addressability for a DMA request > based on the value of the mgaw reported from the IOMMU. However, this > is a fused value and as mentioned in the spec, the guest width > should be calcu

[PATCH 5.4 v3 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

The IOMMU driver calculates the guest addressability for a DMA request based on the value of the mgaw reported from the IOMMU. However, this is a fused value and as mentioned in the spec, the guest width should be calculated based on the minimum of supported adjusted guest address width (SAGAW) and

Re: [PATCH 5.4 v2 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

On Mon, Apr 12, 2021 at 06:25:44PM +, Saeed Mirzamohammadi wrote: > Hi Greg, > > This patch fixes an issue with the IOMMU driver and it only applies to 5.4, > 4.19, and 4.14 stable kernels. May I know when this patch would be available > in the stable kernels? > > Sub

Re: [PATCH 5.4 v2 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

Hi Greg, This patch fixes an issue with the IOMMU driver and it only applies to 5.4, 4.19, and 4.14 stable kernels. May I know when this patch would be available in the stable kernels? Subject: iommu/vt-d: Fix agaw for a supported 48 bit guest address width Thanks, Saeed > On Apr 11, 2

Re: [PATCH 5.4 v2 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

I guess you need to ask Greg KH with this Cc-ing to sta...@vger.kernel.org. Best regards, baolu On 2021/4/12 3:36, Saeed Mirzamohammadi wrote: Hi Lu, Thanks for the review. May I know when do we expect this to be applied to 5.4? Thanks, Saeed On Apr 7, 2021, at 5:25 PM, Lu Baolu

Re: [PATCH] iommu/vt-d: Fix an error handling path in 'intel_prepare_irq_remapping()'

On 4/11/21 3:08 PM, Christophe JAILLET wrote: If 'intel_cap_audit()' fails, we should return directly, as already done in the surrounding error handling path. Fixes: ad3d19029979 ("iommu/vt-d: Audit IOMMU Capabilities and add helper functions") Signed-off-by: Christophe JAI

[PATCH] iommu/vt-d: Fix an error handling path in 'intel_prepare_irq_remapping()'

If 'intel_cap_audit()' fails, we should return directly, as already done in the surrounding error handling path. Fixes: ad3d19029979 ("iommu/vt-d: Audit IOMMU Capabilities and add helper functions") Signed-off-by: Christophe JAILLET --- This patch is completely speculati

Re: [PATCH 1/1] iommu/vt-d: Fix build error of pasid_enable_wpe() with !X86

On 4/10/21 11:23 PM, Lu Baolu wrote: > Commit f68c7f539b6e9 ("iommu/vt-d: Enable write protect for supervisor > SVM") added pasid_enable_wpe() which hit below compile error with !X86. > > ../drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe': > ..

[PATCH 1/1] iommu/vt-d: Fix build error of pasid_enable_wpe() with !X86

Commit f68c7f539b6e9 ("iommu/vt-d: Enable write protect for supervisor SVM") added pasid_enable_wpe() which hit below compile error with !X86. ../drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe': ../drivers/iommu/intel/pasid.c:554:22: error: implicit declaration of

Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

...@lists.linux-foundation.org; linux-kernel@vger.kernel.org Cc: baolu...@linux.intel.com; David Woodhouse ; Nadav Amit ; Alex Williamson ; Kevin Tian ; Gonglei (Arei) ; sta...@vger.kernel.org Subject: Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage Hi Longpeng, On 4/7/21 2

RE: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

lu...@linux.intel.com; David Woodhouse ; Nadav > Amit ; Alex Williamson ; > Kevin Tian ; Gonglei (Arei) ; > sta...@vger.kernel.org > Subject: Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating > superpage > > Hi Longpeng, > > On 4/7/21 2:35 PM, Longpeng (M

Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

...@lists.linux-foundation.org; linux-kernel@vger.kernel.org Cc: baolu...@linux.intel.com; David Woodhouse ; Nadav Amit ; Alex Williamson ; Kevin Tian ; Gonglei (Arei) ; sta...@vger.kernel.org Subject: Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage Hi Longpeng, On 4/1/21 3:18

Re: [PATCH 5.4 v2 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

On 4/8/21 2:40 AM, Saeed Mirzamohammadi wrote: The IOMMU driver calculates the guest addressability for a DMA request based on the value of the mgaw reported from the IOMMU. However, this is a fused value and as mentioned in the spec, the guest width should be calculated based on the minimum of s

Re: [PATCH][next] regmap-irq: Fix dereference of a potentially null d->virt_buf

On Tue, 6 Apr 2021 17:40:02 +0100, Colin King wrote: > The clean up of struct d can potentiallly index into a null array > d->virt_buf causing errorenous pointer dereferencing issues on > kfree calls. Fix this by adding a null check on d->virt_buf before > attempting to tra

[PATCH 5.4 v2 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

The IOMMU driver calculates the guest addressability for a DMA request based on the value of the mgaw reported from the IOMMU. However, this is a fused value and as mentioned in the spec, the guest width should be calculated based on the minimum of supported adjusted guest address width (SAGAW) and

Re: [PATCH 1/1] iommu/vt-d: Report right snoop capability when using FL for IOVA

On Tue, Mar 30, 2021 at 10:11:45AM +0800, Lu Baolu wrote: > drivers/iommu/intel/pasid.h | 1 + > drivers/iommu/intel/iommu.c | 11 ++- > drivers/iommu/intel/pasid.c | 16 > 3 files changed, 27 insertions(+), 1 deletion(-) Applied, thanks.

Re: [PATCH 0/5] iommu/vt-d: Several misc cleanups

On Tue, Mar 23, 2021 at 09:05:55AM +0800, Lu Baolu wrote: > Lu Baolu (5): > iommu/vt-d: Remove unused dma map/unmap trace events > iommu/vt-d: Remove svm_dev_ops > iommu/vt-d: Remove SVM_FLAG_PRIVATE_PASID > iommu/vt-d: Remove unused function declarations > iommu/vt-d:

Re: [PATCH v2 1/1] iommu/vt-d: Don't set then clear private data in prq_event_thread()

On Sat, Mar 20, 2021 at 10:41:56AM +0800, Lu Baolu wrote: > drivers/iommu/intel/svm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks.

Re: [PATCH v2 1/1] iommu/vt-d: Fix lockdep splat in intel_pasid_get_entry()

On Sat, Mar 20, 2021 at 10:09:16AM +0800, Lu Baolu wrote: > drivers/iommu/intel/pasid.c | 21 + > 1 file changed, 13 insertions(+), 8 deletions(-) Applied, thanks.

RE: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

lu...@linux.intel.com; David Woodhouse ; Nadav > Amit ; Alex Williamson ; > Kevin Tian ; Gonglei (Arei) ; > sta...@vger.kernel.org > Subject: Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating > superpage > > Hi Longpeng, > > On 4/1/21 3:18 PM, Longpeng(Mike) wro

Re: [PATCH v5.4 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

Hi Saeed, On 4/7/21 12:35 AM, Saeed Mirzamohammadi wrote: The IOMMU driver calculates the guest addressability for a DMA request based on the value of the mgaw reported from the IOMMU. However, this is a fused value and as mentioned in the spec, the guest width should be calculated based on the

[PATCH][next] regmap-irq: Fix dereference of a potentially null d->virt_buf

From: Colin Ian King The clean up of struct d can potentiallly index into a null array d->virt_buf causing errorenous pointer dereferencing issues on kfree calls. Fix this by adding a null check on d->virt_buf before attempting to traverse the array to kfree the objects. Addresses-Co

[PATCH v5.4 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

The IOMMU driver calculates the guest addressability for a DMA request based on the value of the mgaw reported from the IOMMU. However, this is a fused value and as mentioned in the spec, the guest width should be calculated based on the supported adjusted guest address width (SAGAW). This is from

Re: [PATCH v2 4/5] iommu/vt-d: Use user privilege for RID2PASID translation

(Supervisor Request Enable) field in the pasid table entry of RID2PASID so that requests requesting the supervisor privilege are blocked and treated as DMA remapping faults. Suggested-by: Jacob Pan Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Signed-off-by: Lu Baolu We

Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

occurs.     (d)    DMA UNMAP 0,0xc000    } The page table(only focus on IOVA 0) after (a) is:   PML4: 0x19db5c1003   entry:0x899bdcd2f000    PDPE: 0x1a1cacb003  entry:0x89b35b5c1000     PDE: 0x1a30a72003  entry:0x89b39cacb000 PTE: 0x21d200803  entry:0x89b3b0a72000 The

Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

Hi Longpeng, On 4/1/21 3:18 PM, Longpeng(Mike) wrote: diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index ee09323..cbcb434 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2342,9 +2342,20 @@ static inline int hardware_largepage_caps(struct

Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

obability. >> >> 1.mmap(4GB,MAP_HUGETLB) >> 2. >>    while (1) { >>     (a)    DMA MAP   0,0xa >>     (b)    DMA UNMAP 0,0xa >>     (c)    DMA MAP   0,0xc000 >>   * DMA read IOVA 0 may failure here (Not present) >

Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

(b)DMA UNMAP 0,0xa (c)DMA MAP 0,0xc000 * DMA read IOVA 0 may failure here (Not present) * if the problem occurs. (d)DMA UNMAP 0,0xc000 } The page table(only focus on IOVA 0) after (a) is: PML4: 0x19db5c1003 entry

[PATCH] iommu/vt-d: Force to flush iotlb before creating superpage

0,0xc000 * DMA read IOVA 0 may failure here (Not present) * if the problem occurs. (d)DMA UNMAP 0,0xc000 } The page table(only focus on IOVA 0) after (a) is: PML4: 0x19db5c1003 entry:0x899bdcd2f000 PDPE: 0x1a1cacb003 entry:0x89b35b5c1000 PDE

Re: [PATCH v2 1/4] iommu/vt-d: Enable write protect for supervisor SVM

On 3/30/21 10:52 AM, Jacob Pan wrote: > Hi Guenter, > > On Mon, 22 Mar 2021 10:53:38 -0700, Guenter Roeck > wrote: > >> On Tue, Mar 02, 2021 at 02:13:57AM -0800, Jacob Pan wrote: >>> Write protect bit, when set, inhibits supervisor writes to the read-only >>> pages. In supervisor shared virtual

Re: [PATCH v2 1/4] iommu/vt-d: Enable write protect for supervisor SVM

Hi Guenter, On Mon, 22 Mar 2021 10:53:38 -0700, Guenter Roeck wrote: > On Tue, Mar 02, 2021 at 02:13:57AM -0800, Jacob Pan wrote: > > Write protect bit, when set, inhibits supervisor writes to the read-only > > pages. In supervisor shared virtual addressing (SVA), where page tables > > are share

[PATCH 01/16] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes

From: Paul Kocialkowski As some D-PHY controllers support both Rx and Tx mode, we need a way for users to explicitly request one or the other. For instance, Rx mode can be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI. Introduce new MIPI D-PHY PHY submodes to use with

[PATCH 1/1] iommu/vt-d: Report right snoop capability when using FL for IOVA

The Intel VT-d driver checks wrong register to report snoop capablility when using first level page table for GPA to HPA translation. This might lead the IOMMU driver to say that it supports snooping control, but in reality, it does not. Fix this by always setting PASID-table-entry.PGSNP whenever

[PATCH 8/8] iommu/vt-d: fix a couple of spelling mistakes

There are several spelling mistakes, as follows: guarentees ==> guarantees resgister ==> register insufficent ==> insufficient creats ==> creates tabke ==> take Signed-off-by: Zhen Lei --- drivers/iommu/intel/dmar.c | 6 +++--- drivers/iommu/intel/iommu.c | 2 +- drivers/iommu/i

[PATCH v2 2/4] iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining

Now that the core code handles flushing per-IOVA domain CPU rcaches, remove the handling here. Reviewed-by: Lu Baolu Signed-off-by: John Garry --- drivers/iommu/intel/iommu.c | 31 --- include/linux/cpuhotplug.h | 1 - 2 files changed, 32 deletions(-) diff --git a

Re: [PATCH 3/5] iommu/vt-d: Remove SVM_FLAG_PRIVATE_PASID

Hi Christoph, On 3/24/21 1:33 AM, Christoph Hellwig wrote: On Tue, Mar 23, 2021 at 09:05:58AM +0800, Lu Baolu wrote: The SVM_FLAG_PRIVATE_PASID has never been referenced in the tree, and there's no plan to have anything to use it. So cleanup it. Signed-off-by: Lu Baolu Looks good, Reviewed

Re: [PATCH 5/5] iommu/vt-d: Make unnecessarily global functions static

On Tue, Mar 23, 2021 at 09:06:00AM +0800, Lu Baolu wrote: > Make some functions static as they are only used inside pasid.c. > > Signed-off-by: Lu Baolu Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 4/5] iommu/vt-d: Remove unused function declarations

On Tue, Mar 23, 2021 at 09:05:59AM +0800, Lu Baolu wrote: > Some functions have been deprecated. Remove the remaining function > delarations. s/deprecated/removed/g Otherwise looks good: Reviewed-by: Christoph Hellwig

Re: [PATCH 3/5] iommu/vt-d: Remove SVM_FLAG_PRIVATE_PASID

On Tue, Mar 23, 2021 at 09:05:58AM +0800, Lu Baolu wrote: > The SVM_FLAG_PRIVATE_PASID has never been referenced in the tree, and > there's no plan to have anything to use it. So cleanup it. > > Signed-off-by: Lu Baolu Looks good, Reviewed-by: Christoph Hellwig But can we take this a little f

Re: [PATCH 2/5] iommu/vt-d: Remove svm_dev_ops

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 1/5] iommu/vt-d: Remove unused dma map/unmap trace events

On Tue, Mar 23, 2021 at 09:05:56AM +0800, Lu Baolu wrote: > With commit c588072bba6b5 ("iommu/vt-d: Convert intel iommu driver to > the iommu ops"), the trace events for dma map/unmap have no users any > more. Cleanup them to make the code neat. > > Signed-off-by: Lu Baol

Re: [PATCH 2/3] iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining

On 3/1/21 8:12 PM, John Garry wrote: Now that the core code handles flushing per-IOVA domain CPU rcaches, remove the handling here. Signed-off-by: John Garry --- drivers/iommu/intel/iommu.c | 31 --- include/linux/cpuhotplug.h | 1 - 2 files changed, 32 deletio

  1   2   3   4   5   6   7   8   9   10   >