On Sat, 2 Nov 2024 at 11:38, Jarkko Sakkinen wrote:
>
> On Sat Nov 2, 2024 at 11:02 AM EET, Ard Biesheuvel wrote:
> > Same for the ioctl() [as well as the read-write sysfs node]: looking
> > at the code (patch 19/20) it doesn't seem like user space needs to be
> > a
On Sat, 2 Nov 2024 at 07:29, Jarkko Sakkinen wrote:
>
> On Sat Nov 2, 2024 at 8:22 AM EET, Jarkko Sakkinen wrote:
> > DRTM needs to be able to set the locality used by kernel. Provide
> > TPM_IOC_SET_LOCALITY operation for this purpose. It is enabled only if
> > the kernel command-line has 'tpm.se
On Fri, 1 Nov 2024 at 01:40, Jarkko Sakkinen wrote:
>
> On Fri Nov 1, 2024 at 2:33 AM EET, Jarkko Sakkinen wrote:
> > On Fri Nov 1, 2024 at 1:08 AM EET, Thomas Gleixner wrote:
> > > On Fri, Nov 01 2024 at 00:37, Jarkko Sakkinen wrote:
> > > > On Thu Oct 31, 2024 at 9:25 PM EET, Thomas Gleixner wro
On Thu, 29 Aug 2024 at 15:24, Jonathan McDowell wrote:
>
> On Wed, Aug 28, 2024 at 01:19:16PM -0700, ross.philip...@oracle.com wrote:
> > On 8/28/24 10:14 AM, Ard Biesheuvel wrote:
> > > On Wed, 28 Aug 2024 at 19:09, kernel test robot wrote:
> > > >
> > &
On Wed, 28 Aug 2024 at 19:09, kernel test robot wrote:
>
> Hi Ross,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on tip/x86/core]
> [also build test WARNING on char-misc/char-misc-testing
> char-misc/char-misc-next char-misc/char-misc-linus
> herbert-c
be at a fixed offset, the offsets in the header must be relative
> offsets from the start of the setup kernel. The support in the linker
> file achieves this.
>
> Signed-off-by: Ross Philipson
> Suggested-by: Ard Biesheuvel
Reviewed-by: Ard Biesheuvel
> ---
> ar
d after the EFI stub does Exit Boot Services.
>
> Signed-off-by: Ross Philipson
Reviewed-by: Ard Biesheuvel
> ---
> drivers/firmware/efi/libstub/efistub.h | 8 ++
> drivers/firmware/efi/libstub/x86-stub.c | 98 +
> 2 files changed, 106 insertions(+)
On Tue, 4 Jun 2024 at 19:34, wrote:
>
> On 6/4/24 10:27 AM, Ard Biesheuvel wrote:
> > On Tue, 4 Jun 2024 at 19:24, wrote:
> >>
> >> On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
> >>> On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
> >>>>
On Tue, 4 Jun 2024 at 19:24, wrote:
>
> On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
> > On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
> >>
> >> Hello Ross,
> >>
> >> On Fri, 31 May 2024 at 03:32, Ross Philipson
> >> wrote:
> &g
On Fri, 31 May 2024 at 16:04, Ard Biesheuvel wrote:
>
> On Fri, 31 May 2024 at 15:33, Ard Biesheuvel wrote:
> >
> > On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
> > >
> > > Hello Ross,
> > >
> > > On Fri, 31 May 2024 at 03:32, Ro
On Fri, 31 May 2024 at 15:33, Ard Biesheuvel wrote:
>
> On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
> >
> > Hello Ross,
> >
> > On Fri, 31 May 2024 at 03:32, Ross Philipson
> > wrote:
> > >
> > > The Secure Launch (SL) stub provi
On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
>
> Hello Ross,
>
> On Fri, 31 May 2024 at 03:32, Ross Philipson
> wrote:
> >
> > The Secure Launch (SL) stub provides the entry point for Intel TXT (and
> > later AMD SKINIT) to vector to during the late lau
On Fri, 31 May 2024 at 03:32, Ross Philipson wrote:
>
> This support allows the DRTM launch to be initiated after an EFI stub
> launch of the Linux kernel is done. This is accomplished by providing
> a handler to jump to when a Secure Launch is in progress. This has to be
> called after the EFI st
Hello Ross,
On Fri, 31 May 2024 at 03:32, Ross Philipson wrote:
>
> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
> later AMD SKINIT) to vector to during the late launch. The symbol
> sl_stub_entry is that entry point and its offset into the kernel is
> conveyed to the l
On Mon, 14 Mar 2022 at 11:37, Eric Auger wrote:
>
> Hi Robin
>
> On 3/11/22 11:34 AM, Robin Murphy wrote:
> > On 2022-03-11 08:19, Eric Auger wrote:
> >> Hi guys,
> >>
> >> On 2/21/22 4:43 PM, Shameer Kolothum wrote:
> >>> Hi,
> >>>
> >>> Since we now have an updated verion[0] of IORT spec(E.d) wh
On Thu, 4 Nov 2021 at 14:40, Walter Wu wrote:
>
> On Thu, 2021-11-04 at 13:47 +0100, Ard Biesheuvel wrote:
> > On Thu, 4 Nov 2021 at 13:31, Walter Wu
> > wrote:
> > >
> > > On Thu, 2021-11-04 at 09:57 +0100, Ard Biesheuvel wrote:
> > > >
On Thu, 4 Nov 2021 at 13:31, Walter Wu wrote:
>
> On Thu, 2021-11-04 at 09:57 +0100, Ard Biesheuvel wrote:
> > On Thu, 4 Nov 2021 at 09:53, Christoph Hellwig wrote:
> > >
> > > On Thu, Nov 04, 2021 at 10:32:21AM +0800, Walter Wu wrote:
> > > > diff --
On Thu, 4 Nov 2021 at 09:53, Christoph Hellwig wrote:
>
> On Thu, Nov 04, 2021 at 10:32:21AM +0800, Walter Wu wrote:
> > diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
> > index f36be5166c19..6c7d1683339c 100644
> > --- a/include/linux/set_memory.h
> > +++ b/include/linux/set
On Mon, 1 Nov 2021 at 13:21, Walter Wu wrote:
>
> Hi Ard,
>
> On Mon, 2021-11-01 at 09:34 +0100, Ard Biesheuvel wrote:
> > On Mon, 1 Nov 2021 at 04:17, Walter Wu
> > wrote:
> > >
> > > DMA_ATTR_NO_KERNEL_MAPPING is to avoid creating a kernel mapping
&
On Mon, 1 Nov 2021 at 04:17, Walter Wu wrote:
>
> DMA_ATTR_NO_KERNEL_MAPPING is to avoid creating a kernel mapping
> for the allocated buffer, but current implementation is that
> PTE of allocated buffer in kernel page table is valid. So we
> should set invalid for PTE of allocate buffer so that t
On Thu, 5 Aug 2021 at 15:35, Shameerali Kolothum Thodi
wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel [mailto:a...@kernel.org]
> > Sent: 05 August 2021 14:23
> > To: Shameerali Kolothum Thodi
> > Cc: Linux ARM ; ACPI Devel Malin
On Thu, 5 Aug 2021 at 10:10, Shameer Kolothum
wrote:
>
> Hi,
>
> The series adds support to IORT RMR nodes specified in IORT
> Revision E.b -ARM DEN 0049E[0]. RMR nodes are used to describe
> memory ranges that are used by endpoints and require a unity
> mapping in SMMU.
>
> We have faced issues w
On Wed, 21 Oct 2020 at 14:35, Nicolas Saenz Julienne
wrote:
>
> Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
> physical address addressable by all DMA masters in the system. It's
> specially useful for setting memory zones sizes at early boot time.
>
> Signed-off-by: Nico
On Thu, 15 Oct 2020 at 12:31, Lorenzo Pieralisi
wrote:
>
> On Wed, Oct 14, 2020 at 09:12:09PM +0200, Nicolas Saenz Julienne wrote:
>
> [...]
>
> > +unsigned int __init acpi_iort_get_zone_dma_size(void)
> > +{
> > + struct acpi_table_iort *iort;
> > + struct acpi_iort_node *node, *end;
> >
On Fri, 16 Oct 2020 at 08:51, Hanjun Guo wrote:
>
> On 2020/10/16 2:03, Catalin Marinas wrote:
> > On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote:
> >> On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
> >>> From: Ard Biesheuvel
> >>&
On Thu, 15 Oct 2020 at 11:16, Nicolas Saenz Julienne
wrote:
>
> On Thu, 2020-10-15 at 08:56 +0200, Ard Biesheuvel wrote:
> > On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote:
> > > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
> > > wrote:
> > >
On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote:
>
> On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
> wrote:
> >
> > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
> > physical address addressable by all DMA masters in the system. It's
> > specially useful for sett
On Mon, 12 Oct 2020 at 13:37, Catalin Marinas wrote:
>
> On Sat, Oct 10, 2020 at 05:12:31PM +0200, Nicolas Saenz Julienne wrote:
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index f6902a2b4ea6..0eca5865dcb1 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
>
Hi Nicolas,
$SUBJECT is out of sync with the patch below. Also, for legibility, it
helps if the commit log is intelligible by itself, rather than relying
on $SUBJECT being the first line of the first paragraph.
On Sat, 10 Oct 2020 at 17:12, Nicolas Saenz Julienne
wrote:
>
> The function provides
On Fri, 9 Oct 2020 at 19:10, Catalin Marinas wrote:
>
> On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote:
> > On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi
> > wrote:
> > > We can move this check to IORT code and call it from arm64 if it
> > >
On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi
wrote:
>
> On Fri, Oct 09, 2020 at 11:13:59AM +0200, Ard Biesheuvel wrote:
> > On Fri, 9 Oct 2020 at 10:36, Nicolas Saenz Julienne
> > wrote:
> > >
> > > On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
On Fri, 9 Oct 2020 at 10:36, Nicolas Saenz Julienne
wrote:
>
> On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
> > On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
> > > On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> > > &g
On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
>
> On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> > Sadly I just realised that the series is incomplete, we have RPi4 users that
> > want to boot unsing ACPI, and this series would break things for them. I'll
> > hav
(+ Lorenzo)
On Thu, 8 Oct 2020 at 12:14, Catalin Marinas wrote:
>
> On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> > On Fri, 2020-10-02 at 12:55 +0100, Catalin Marinas wrote:
> > > On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote:
> > > > On Thu, 2
udev based autoloading of the SMMU drivers by making
the platform device identifier part of the module alias.
Signed-off-by: Ard Biesheuvel
---
drivers/acpi/arm64/iort.c | 4 ++--
drivers/iommu/arm-smmu-v3.c | 1 +
drivers/iommu/arm-smmu.c| 1 +
3 files changed, 4 insertions(+), 2
On Fri, 22 Nov 2019 at 17:01, Rob Herring wrote:
>
> On Fri, Nov 22, 2019 at 8:55 AM Will Deacon wrote:
> >
> > [+Ard]
> >
> > Hi Rob,
> >
> > On Fri, Nov 22, 2019 at 08:47:46AM -0600, Rob Herring wrote:
> > > On Wed, Nov 20, 2019 at 1:00 PM Will Deacon wrote:
> > > >
> > > > Commit 8e12257dead7
FAR);
> > + cbfrsynra = readl_relaxed(gr1_base +
> > ARM_SMMU_GR1_CBFRSYNRA(cfg->cbndx));
> >
> > dev_err_ratelimited(smmu->dev,
> > - "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x,
> > cb=%d\n",
> > - fsr, i
(+ Bjorn)
On Mon, 28 Jan 2019 at 12:27, Vivek Gautam wrote:
>
> Hi Ard,
>
> On Thu, Jan 24, 2019 at 1:25 PM Ard Biesheuvel
> wrote:
> >
> > On Thu, 24 Jan 2019 at 07:58, Vivek Gautam
> > wrote:
> > >
> > > On Mon, Jan 21, 2019 at 7:55 PM Ard
On Thu, 24 Jan 2019 at 07:58, Vivek Gautam wrote:
>
> On Mon, Jan 21, 2019 at 7:55 PM Ard Biesheuvel
> wrote:
> >
> > On Mon, 21 Jan 2019 at 14:56, Robin Murphy wrote:
> > >
> > > On 21/01/2019 13:36, Ard Biesheuvel wrote:
> > > >
On Mon, 21 Jan 2019 at 14:56, Robin Murphy wrote:
>
> On 21/01/2019 13:36, Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 14:25, Robin Murphy wrote:
> >>
> >> On 21/01/2019 10:50, Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 11:17, Vi
On Mon, 21 Jan 2019 at 14:25, Robin Murphy wrote:
>
> On 21/01/2019 10:50, Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 11:17, Vivek Gautam
> > wrote:
> >>
> >> Hi,
> >>
> >>
> >> On Mon, Jan 21, 2019 at 12:56 PM Ard Biesheuv
On Mon, 21 Jan 2019 at 11:17, Vivek Gautam wrote:
>
> Hi,
>
>
> On Mon, Jan 21, 2019 at 12:56 PM Ard Biesheuvel
> wrote:
> >
> > On Mon, 21 Jan 2019 at 06:54, Vivek Gautam
> > wrote:
> > >
> > > Qualcomm SoCs have an additional level of cac
On Mon, 21 Jan 2019 at 06:54, Vivek Gautam wrote:
>
> Qualcomm SoCs have an additional level of cache called as
> System cache, aka. Last level cache (LLC). This cache sits right
> before the DDR, and is tightly coupled with the memory controller.
> The clients using this cache request their slice
h the on-SoC NIC of the Socionext
SynQuacer, so assuming it works as advertised:
Acked-by: Ard Biesheuvel
for the series.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> On 31 Jan 2018, at 23:31, Thor Thayer wrote:
>
> Hi Ard,
>
>> On 01/31/2018 04:21 PM, Ard Biesheuvel wrote:
>>> On 31 January 2018 at 22:09, Thor Thayer
>>> wrote:
>>> Hi,
>>>
>>> I'm enabling the ARM SMMU-500 on an AR
On 31 January 2018 at 22:09, Thor Thayer wrote:
> Hi,
>
> I'm enabling the ARM SMMU-500 on an ARM64 A53. I'm hitting a data abort in
> the probe functions because I'm accessing the registers in EL1 mode.
>
Why do you think the fact that you are running at EL1 is causing the data abort?
> Linux s
-
> include/linux/iova.h | 8 +--
> 8 files changed, 60 insertions(+), 105 deletions(-)
>
These patches look suspiciously like the ones I have been using over
the past couple of weeks (modulo the tegra and host1x changes) from
your git tree. They work fine on my AMD Over
On 5 May 2017 at 18:11, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:18:31PM -0500, Tom Lendacky wrote:
>> Add a function that will return the E820 type associated with an address
>> range.
>
> ...
>
>> @@ -110,9 +111,28 @@ bool __init e820__mapped_all(u64 start, u64 end, enum
>> e820_type
> On 3 May 2017, at 11:32, Robin Murphy wrote:
>
>> On 28/04/17 14:22, Ard Biesheuvel wrote:
>>> On 28 April 2017 at 14:17, Will Deacon wrote:
>>>> On Fri, Apr 28, 2017 at 02:14:49PM +0100, Ard Biesheuvel wrote:
>>>>> On 28 April
On 28 April 2017 at 14:17, Will Deacon wrote:
> On Fri, Apr 28, 2017 at 02:14:49PM +0100, Ard Biesheuvel wrote:
>> On 28 April 2017 at 14:11, Will Deacon wrote:
>> > Hi Ard,
>> >
>> > [+ devicetree@]
>> >
>> > On Fri, Apr 14, 2017 at 01:4
On 28 April 2017 at 14:11, Will Deacon wrote:
> Hi Ard,
>
> [+ devicetree@]
>
> On Fri, Apr 14, 2017 at 01:43:15PM +0100, Ard Biesheuvel wrote:
>> DT nodes may have a status property, and if they do, such nodes should
>> only be considered present if the stat
PA
Failed to initialise IOMMU /smb/smmu@e060
Failed to initialise IOMMU /smb/smmu@e080
Since this is not an error condition, only call the init function if
the device is enabled, which also inhibits the spurious error messages.
Signed-off-by: Ard Biesheuvel
---
drivers/iommu/of_iommu.c |
52 matches
Mail list logo
