On Fri, May 06 2022 at 23:41, Thomas Gleixner wrote:
> On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
>> Programming an HPET channel as periodic requires setting the
>> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator
>> register must be written twice (once for the
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Programming an HPET channel as periodic requires setting the
> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator
> register must be written twice (once for the comparator value and once for
> the periodic value). Since this
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> + *
> + * Also, NMIs do not have an associated vector. No need for cleanup.
They have a vector and what the heck is this cleanup comment for here?
There is nothing cleanup alike anywhere near.
Adding confusing comments is worse than
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
>
> + if (info->flags & X86_IRQ_ALLOC_AS_NMI) {
> + /* Only one IRQ per NMI */
> + if (nr_irqs != 1)
> + return -EINVAL;
See previous reply.
___
iommu
Whoops! Was going through my unread emails and noticed I somehow missed this
patch last month.
Reviewed-by: Lyude Paul
I will push this to drm-misc-fixes in a little bit (assuming I don't find it
there already)
On Tue, 2022-04-05 at 15:21 +0100, Robin Murphy wrote:
> Even if some IOMMU has
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> The Intel IOMMU interrupt remapping driver already programs correctly the
> delivery mode of individual irqs as per their irq_data. Improve handling
> of NMIs. Allow only one irq per NMI. Also, it is not necessary to cleanup
> irq vectors after
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Vectors are meaningless when allocating IRQs with NMI as the delivery
> mode.
Vectors are not meaningless. NMI has a fixed vector.
The point is that for a fixed vector there is no vector management
required.
Can you spot the difference?
> In
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> There are no restrictions in hardware to set MSI messages with its
> own delivery mode.
"messages with its own" ? Plural/singular confusion.
> Use the mode specified in the provided IRQ hardware
> configuration data. Since most of the IRQs are
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Currently, the delivery mode of all interrupts is set to the mode of the
> APIC driver in use. There are no restrictions in hardware to configure the
> delivery mode of each interrupt individually. Also, certain IRQs need
> to be
Ricardo,
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Certain types of interrupts, such as NMI, do not have an associated vector.
> They, however, target specific CPUs. Thus, when assigning the destination
> CPU, it is beneficial to select the one with the lowest number of
> vectors.
Why
On Fri, May 06, 2022 at 05:44:11PM +0100, Robin Murphy wrote:
> > > Nit: if that's true then it's equally true for iommu_attach_group() as
> > > well.
> >
> > Is it? I didn't check this as closely..
>
> Well, there certainly seems no obvious reason for one to WARN where the
> other fails
On 2022-05-06 14:21, Jason Gunthorpe wrote:
On Fri, May 06, 2022 at 10:12:29AM +0100, Robin Murphy wrote:
On 2022-05-05 17:15, Jason Gunthorpe via iommu wrote:
Call iommu_group_do_attach_device() only from
__iommu_group_attach_domain() which should be used to attach any domain to
the group.
On Mon, 25 Apr 2022 19:41:36 +0800, Yang Yingliang wrote:
> It will cause null-ptr-deref when using 'res', if platform_get_resource()
> returns NULL, so move using 'res' after devm_ioremap_resource() that
> will check it to avoid null-ptr-deref.
> And use devm_platform_get_and_ioremap_resource()
On Fri, 29 Apr 2022 10:22:40 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi Joerg,
>
> this is essentially a resend of v2 with a Acked-by:s from Robin and Will
> added. These have been on the list for quite a while now, but apparently
> there was a misunderstanding, so neither you
On Mon, 25 Apr 2022 19:45:25 +0800, Yang Yingliang wrote:
> It will cause null-ptr-deref if platform_get_resource() returns NULL,
> we need check the return value.
>
>
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] iommu/arm-smmu-v3: check return value after calling
On Mon, 11 Apr 2022 15:20:08 +0530, Rohit Agarwal wrote:
> This series adds devicetree nodes for SDX65. It adds reserved memory
> nodes, SDHCI, smmu and tcsr mutex support.
>
> Changes from v1:
> - Addressed Mani's Comments and made necessary.
> - Rebased on top of v5.18-rc2.
>
> [...]
On Tue, 26 Apr 2022 14:04:45 +0100, Jean-Philippe Brucker wrote:
> We currently call arm64_mm_context_put() without holding a reference to
> the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to
> ensure the mm only gets freed after we unpinned the ASID.
>
>
Applied to will
On Tue, 3 May 2022 09:34:27 -0700, Bjorn Andersson wrote:
> This adds the compatible for the Qualcomm SC8280XP platform and associate the
> Qualcomm impl in the ARM SMMU driver to it.
>
> Bjorn Andersson (2):
> dt-bindings: arm-smmu: Add compatible for Qualcomm SC8280XP
> iommu/arm-smmu-qcom:
On Fri, May 06, 2022 at 08:12:11AM +, Tian, Kevin wrote:
> > From: David Woodhouse
> > Sent: Friday, May 6, 2022 3:17 PM
> >
> > On Fri, 2022-05-06 at 06:49 +, Tian, Kevin wrote:
> > > > From: Baolu Lu
> > > >
> > > > > --- a/include/linux/dmar.h
> > > > > +++ b/include/linux/dmar.h
> >
On Thu, 28 Apr 2022 08:56:38 +0200
Krzysztof Kozlowski wrote:
Hi,
> On 27/04/2022 13:25, Andre Przywara wrote:
> > The Page Request Interface (PRI) is an optional PCIe feature. As such, a
> > SMMU would not need to handle it if the PCIe host bridge or the SMMU
> > itself do not implement it.
The Page Request Interface (PRI) is an optional PCIe feature. As such, a
SMMU would not need to handle it if the PCIe host bridge or the SMMU
itself do not implement it. Also an SMMU could be connected to a platform
device, without any PRI functionality whatsoever.
In all cases there would be no
On Fri, May 06, 2022 at 02:35:50PM +0100, Robin Murphy wrote:
> > So you want to say "DMA is always managed" when attaching a domain of
> > type IOMMU_DOMAIN_UNMANAGED? :)
>
> Touché ;) Just goes to confirm the point above that confusion between
> general concepts and specific API terms is all
On 2022-05-06 14:10, Jason Gunthorpe wrote:
On Fri, May 06, 2022 at 10:32:50AM +0100, Robin Murphy wrote:
It is as discussed with Robin, NULL means to return the group back to
some platform defined translation, and in some cases this means
returning back to work with the platform's DMA ops -
On Fri, May 06, 2022 at 10:12:29AM +0100, Robin Murphy wrote:
> On 2022-05-05 17:15, Jason Gunthorpe via iommu wrote:
> > Call iommu_group_do_attach_device() only from
> > __iommu_group_attach_domain() which should be used to attach any domain to
> > the group.
> >
> > The only unique thing
On Fri, May 06, 2022 at 10:32:50AM +0100, Robin Murphy wrote:
> > > It is as discussed with Robin, NULL means to return the group back to
> > > some platform defined translation, and in some cases this means
> > > returning back to work with the platform's DMA ops - presumably if it
> > > isn't
On Fri, May 06, 2022 at 03:25:03PM +1000, David Gibson wrote:
> On Thu, May 05, 2022 at 04:07:28PM -0300, Jason Gunthorpe wrote:
> > When the iommu_domain is created I want to have a
> > iommu-driver-specific struct, so PPC can customize its iommu_domain
> > however it likes.
>
> This requires
On Fri, 22 Apr 2022 22:17:20 +0100,
Linus Walleij wrote:
>
> On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
>
> > arm is the last platform not using the dma-direct code for directly
> > mapped DMA. With the dmaboune removal from Arnd we can easily switch
> > arm to always use
On Fri, May 06, 2022 at 03:51:40AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, May 5, 2022 10:08 PM
> >
> > On Thu, May 05, 2022 at 07:40:37AM +, Tian, Kevin wrote:
> >
> > > In concept this is an iommu property instead of a domain property.
> >
> > Not really,
> From: David Gibson
> Sent: Friday, May 6, 2022 1:25 PM
>
> >
> > When the iommu_domain is created I want to have a
> > iommu-driver-specific struct, so PPC can customize its iommu_domain
> > however it likes.
>
> This requires that the client be aware of the host side IOMMU model.
> That's
On 2022/5/6 03:27, Jason Gunthorpe wrote:
On Thu, May 05, 2022 at 07:56:59PM +0100, Robin Murphy wrote:
Ack to that, there are certainly further improvements to consider once we've
got known-working code into a released kernel, but let's not get ahead of
ourselves just now.
Yes please
On 2022-05-06 00:28, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Thursday, May 5, 2022 11:33 PM
/*
-* If the group has been claimed already, do not re-attach the default
-* domain.
+* New drivers should support default domains and so the
detach_dev() op
+
On 2022-05-05 17:15, Jason Gunthorpe via iommu wrote:
Call iommu_group_do_attach_device() only from
__iommu_group_attach_domain() which should be used to attach any domain to
the group.
The only unique thing __iommu_attach_group() does is to check if the group
is already attached to some caller
> From: David Woodhouse
> Sent: Friday, May 6, 2022 3:17 PM
>
> On Fri, 2022-05-06 at 06:49 +, Tian, Kevin wrote:
> > > From: Baolu Lu
> > >
> > > > --- a/include/linux/dmar.h
> > > > +++ b/include/linux/dmar.h
> > > > @@ -19,7 +19,7 @@
> > > > struct acpi_dmar_header;
> > > >
> > > >
> From: Rodel, Jorg
> Sent: Friday, May 6, 2022 3:11 PM
>
> On Fri, May 06, 2022 at 06:49:43AM +, Tian, Kevin wrote:
> > another nit: dmar is intel specific thus CONFIG_X86 is always true.
>
> There are Itanium systems which have DMAR units. Is that no longer
> supported?
>
Sorry I just
On 2022/5/6 14:10, Tian, Kevin wrote:
From: Lu Baolu
Sent: Friday, May 6, 2022 1:27 PM
+
+/*
+ * Set the page snoop control for a pasid entry which has been set up.
+ */
+void intel_pasid_setup_page_snoop_control(struct intel_iommu *iommu,
+ struct device
On Fri, May 06 2022 at 09:49, Zhangfei Gao wrote:
> Will this be taken for 5.18?
It's queued in tip core/urgent and will go to Linus this week.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Fri, 2022-05-06 at 06:49 +, Tian, Kevin wrote:
> > From: Baolu Lu
> >
> > > --- a/include/linux/dmar.h
> > > +++ b/include/linux/dmar.h
> > > @@ -19,7 +19,7 @@
> > > struct acpi_dmar_header;
> > >
> > > #ifdef CONFIG_X86
> > > -# define DMAR_UNITS_SUPPORTEDMAX_IO_APICS
> > > +#
On Fri, May 06, 2022 at 06:49:43AM +, Tian, Kevin wrote:
> another nit: dmar is intel specific thus CONFIG_X86 is always true.
There are Itanium systems which have DMAR units. Is that no longer
supported?
Regards,
--
Jörg Rödel
jroe...@suse.de
SUSE Software Solutions Germany GmbH
> From: Baolu Lu
> Sent: Friday, May 6, 2022 1:57 PM
>
> On 2022/5/6 03:46, Steve Wahl wrote:
> > Increase DMAR_UNITS_SUPPORTED to support 64 sockets with 10 DMAR
> units
> > each, for a total of 640.
> >
> > If the available hardware exceeds DMAR_UNITS_SUPPORTED (previously
> set
> > to
> From: Lu Baolu
> Sent: Friday, May 6, 2022 1:27 PM
> +
> +/*
> + * Set the page snoop control for a pasid entry which has been set up.
> + */
> +void intel_pasid_setup_page_snoop_control(struct intel_iommu *iommu,
> + struct device *dev, u32 pasid)
> +{
> +
40 matches
Mail list logo
