On 07.07.22 11:39, Marc Zyngier wrote:
Hello Marc
> On Sun, 03 Jul 2022 16:22:03 +0100,
> Oleksandr wrote:
>>
>> On 01.07.22 23:00, Samuel Holland wrote:
>>
>>
>> Hello Samuel
>>
>>> Some architectures and irqchip drivers modify the cpumask
ng irq_data_update_affinity()
only, but here we also reuse irq_data_update_effective_affinity(), so I
would mention that in the description.
Reviewed-by: Oleksandr Tyshchenko # Xen bits
[snip]
--
Regards,
Oleksandr Tyshchenko
___
iommu mailing list
iommu@lists.linux-founda
From: Oleksandr Tyshchenko
The main purpose of this binding is to communicate Xen specific
information using generic IOMMU device tree bindings (which is
a good fit here) rather than introducing a custom property.
Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
to be used
On 01.06.22 03:34, Stefano Stabellini wrote:
Hello Stefano
On Tue, 31 May 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The main purpose of this binding is to communicate Xen specific
information using generic IOMMU device tree bindings (which is
a good fit here) rather
On 31.05.22 14:52, Krzysztof Kozlowski wrote:
Hello Krzysztof
On 30/05/2022 23:00, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Thank you for your patch. There is something to discuss/improve.
diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
b
From: Oleksandr Tyshchenko
The main purpose of this binding is to communicate Xen specific
information using generic IOMMU device tree bindings (which is
a good fit here) rather than introducing a custom property.
Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
to be used
On pátek 25. března 2022 20:27:43 CET Linus Torvalds wrote:
> On Fri, Mar 25, 2022 at 12:26 PM Oleksandr Natalenko
> wrote:
> >
> > On pátek 25. března 2022 19:30:21 CET Linus Torvalds wrote:
> > > The reason the ath9k issue was found quickly
> > > is very li
Wi-Fi printer
definitely helps in finding the issue too.
--
Oleksandr Natalenko (post-factum)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
return false;
> - }
>
> __skb_unlink(skb, &rx_edma->rx_fifo);
> if (ret == -EINVAL) {
With this patch and both ddbd89deb7d3+aa6f8dcbab47 in place the AP works for me.
Thanks.
--
Oleksandr Natalenko (post-factum)
_
) wrong but getting away with it until now. If ddbd89deb7d3
> > alone turns out to work OK then I'd be inclined to try a partial revert of
> > just that one hunk.
>
> Agreed. Let's try that first.
>
> Oleksandr, can you try the patch below:
>
>
> diff -
Hello.
On středa 23. března 2022 18:27:21 CET Linus Torvalds wrote:
> On Wed, Mar 23, 2022 at 12:19 AM Oleksandr Natalenko
> wrote:
> > These commits appeared in v5.17 and v5.16.15, and both kernels are
> > broken for me. I'm pretty confident these commits make the di
Hello.
The following upstream commits:
aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE
break ath9k-based Wi-Fi access point for me. The AP emits beacons, but no
client can connect to it, either from the very beginning, o
Hi, all.
Gentle reminder.
On 05.09.17 19:52, Oleksandr wrote:
Hi, Magnus, maintainers, all.
On 19.06.17 14:04, Magnus Damm wrote:
iommu/ipmmu-vmsa: r8a7796 support V4
[PATCH v4 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
[PATCH v4 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
Hi, Magnus, maintainers, all.
On 19.06.17 14:04, Magnus Damm wrote:
iommu/ipmmu-vmsa: r8a7796 support V4
[PATCH v4 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
[PATCH v4 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
[PATCH v4 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
Hi Laurent, Robin
On Tue, Aug 29, 2017 at 4:01 PM, Laurent Pinchart
wrote:
> Hi Oleksandr,
>
> Thank you for the patch.
>
> On Wednesday, 23 August 2017 17:31:42 EEST Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Reserving a free context is bot
Hi, all.
Any comments?
On Wed, Aug 23, 2017 at 5:31 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> Reserving a free context is both quicker and more likely to fail
> (due to limited hardware resources) than setting up a pagetable.
> What is more the pagetab
From: Oleksandr Tyshchenko
Reserving a free context is both quicker and more likely to fail
(due to limited hardware resources) than setting up a pagetable.
What is more the pagetable init/cleanup code could require
the context to be set up.
Signed-off-by: Oleksandr Tyshchenko
CC: Robin Murphy
Hi, Laurent
On Wed, Aug 23, 2017 at 4:46 PM, Laurent Pinchart
wrote:
> Hi Oleksandr,
>
> On Wednesday, 23 August 2017 14:58:47 EEST Oleksandr Tyshchenko wrote:
>> On Wed, Aug 23, 2017 at 1:05 PM, Robin Murphy wrote:
>> > On 23/08/17 10:36, Oleksandr Tyshchenko wrote:
&g
Hi, Robin
On Wed, Aug 23, 2017 at 1:05 PM, Robin Murphy wrote:
> On 23/08/17 10:36, Oleksandr Tyshchenko wrote:
>> Hi, Laurent.
>>
>> On Wed, Aug 23, 2017 at 12:25 AM, Laurent Pinchart
>> wrote:
>>> Hi Oleksandr,
>>>
>>> Thank you for the
Hi, Laurent.
On Wed, Aug 23, 2017 at 12:25 AM, Laurent Pinchart
wrote:
> Hi Oleksandr,
>
> Thank you for the patch.
>
> On Monday, 21 August 2017 15:40:41 EEST Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> In ipmmu_domain_init_context() we a
Hi,
On Tue, Aug 22, 2017 at 5:24 PM, Joerg Roedel wrote:
> On Mon, Aug 21, 2017 at 03:40:41PM +0300, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> In ipmmu_domain_init_context() we are trying to allocate context and
>> if allocation fails we wi
From: Oleksandr Tyshchenko
In ipmmu_domain_init_context() we are trying to allocate context and
if allocation fails we will call free_io_pgtable_ops(),
but "domain->context_id" hasn't been initialized yet (likely it is 0
because of kzalloc). Having the following call stack:
f
On Thu, Mar 16, 2017 at 1:19 PM, Robin Murphy wrote:
> On 16/03/17 09:19, Oleksandr Tyshchenko wrote:
>> Hi, all.
>>
>> Any comments?
>
> Er, no, but in a good way ;)
>
> Patches look fine to me, and I see Will's already queued them anyway.
>
> Thanks
Hi, all.
Any comments?
On Mon, Feb 27, 2017 at 2:30 PM, Oleksandr Tyshchenko
wrote:
> Hi.
>
> There is a small patch series which contains the same fix for both
> descriptor formats based on the preceding RFC patches:
> https://lists.linuxfoundation.org/pipermail/iommu/2017-Febru
From: Oleksandr Tyshchenko
Do a check for already installed leaf entry at the current level before
dereferencing it in order to avoid walking the page table down with
wrong pointer to the next level.
Signed-off-by: Oleksandr Tyshchenko
CC: Will Deacon
CC: Robin Murphy
---
drivers/iommu/io
From: Oleksandr Tyshchenko
Do a check for already installed leaf entry at the current level before
dereferencing it in order to avoid walking the page table down with
wrong pointer to the next level.
Signed-off-by: Oleksandr Tyshchenko
CC: Will Deacon
CC: Robin Murphy
---
drivers/iommu/io
Hi.
There is a small patch series which contains the same fix for both
descriptor formats based on the preceding RFC patches:
https://lists.linuxfoundation.org/pipermail/iommu/2017-February/020411.html
https://lists.linuxfoundation.org/pipermail/iommu/2017-February/020477.html
Oleksandr
Hi, Robin.
On Tue, Feb 21, 2017 at 2:00 PM, Robin Murphy wrote:
> On 16/02/17 13:52, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Do a check for already installed leaf entry at the current level before
>> performing any actions when trying to map.
Hi, Robin.
It would be greatly appreciated if you could test this patch if nobody
has objections to the patch itself.
On Thu, Feb 16, 2017 at 3:52 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> Do a check for already installed leaf entry at the current lev
From: Oleksandr Tyshchenko
Do a check for already installed leaf entry at the current level before
performing any actions when trying to map.
This check is already present in arm_v7s_init_pte(), i.e. before
installing new leaf entry at the current level if conditions to do so
are met
On Mon, Feb 13, 2017 at 1:27 PM, Will Deacon wrote:
> On Mon, Feb 13, 2017 at 01:07:02PM +0200, Oleksandr Tyshchenko wrote:
>> Any comments?
>
> Looks fine to me, but I don't think it's urgent and I already sent my
> SMMU pull for 4.11. I'll send this as a fix
Hi, all.
Any comments?
On Thu, Feb 9, 2017 at 3:56 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> Do a check for already installed leaf entry at the current level before
> performing any actions when trying to map.
>
> This check is already present in arm_lp
From: Oleksandr Tyshchenko
Do a check for already installed leaf entry at the current level before
performing any actions when trying to map.
This check is already present in arm_lpae_init_pte(), i.e. before
installing new leaf entry at the current level if conditions to do so
are met (size
33 matches
Mail list logo
