[+Mark]
On Wed, Aug 14, 2019 at 05:29:09PM +0530, Bhupesh Sharma wrote:
> On Wed, Aug 14, 2019 at 1:51 PM Will Deacon wrote:
> >
> > On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> > > I still see the following issue on a 48-bit hardware (i.e. _non_
>
On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> I still see the following issue on a 48-bit hardware (i.e. _non_
> ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
> d2d73d2fef421ca0d4 as the HEAD:
Have you tried the patches I posted here:
http://lists.infradead.o
Hi Geert,
On Tue, Aug 13, 2019 at 02:43:23PM +0200, Geert Uytterhoeven wrote:
> On Fri, Aug 9, 2019 at 6:47 PM Will Deacon wrote:
> > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote:
> > > This patch series adds support for 52-bit kernel VAs using some of the
>
On Thu, May 23, 2019 at 02:54:54PM +0100, Jean-Philippe Brucker wrote:
> On 23/05/2019 14:02, Daniel Borkmann wrote:
> > On 05/23/2019 12:36 PM, Will Deacon wrote:
> >> [+Daniel and Jean-Philippe]
> >>
> >> On Thu, May 23, 2019 at 05:12:00PM +0900, Yoshihir
[+Daniel and Jean-Philippe]
On Thu, May 23, 2019 at 05:12:00PM +0900, Yoshihiro Shimoda wrote:
> The following build warning happens on gcc 8.1.0.
>
> linux/arch/arm64/include/asm/insn.h: In function 'aarch64_insn_is_ldadd':
> linux/arch/arm64/include/asm/insn.h:280:257: warning: bitwise compar
On Thu, Dec 27, 2018 at 11:12:25AM +0100, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
>
> Thanks for the report!
>
> CC Will (commit author), Arnd (compiler collective).
>
> On Thu, Dec 27, 2018 at 2:58 AM Yoshihiro Shimoda
> wrote:
> > > From: Geert Uytterhoeven, Sent: Wednesday, December 26,
On Thu, Apr 19, 2018 at 04:06:07PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
Thanks, W
On Mon, Feb 26, 2018 at 04:16:19PM +0100, Geert Uytterhoeven wrote:
> On Mon, Feb 5, 2018 at 5:42 PM, Mark Rutland wrote:
> > To support ACPI systems, we need to request IRQs before CPUs are
> > hotplugged, and thus we need to request IRQs before we know their
> > associated PMU.
> >
> > This is p
On Fri, Dec 15, 2017 at 04:59:28PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 15, 2017 at 3:27 PM, Will Deacon wrote:
> > On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
> >> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin wrote:
> >> > The
On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin wrote:
> > The two important differences here seem to be
> >
> > 1) Staging the state via current->thread.fpsimd_state instead of loading
> > directly:
> >
> > - fpsimd_load_st
Hi Geert,
On Thu, Dec 14, 2017 at 03:34:50PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 11:20 AM, Geert Uytterhoeven
> wrote:
> > During userspace (Debian jessie NFS root) boot on arm64:
> >
> > rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
> > esr 0x92000
Hi Geert,
Thanks for trying to bisect this.
On Tue, Dec 12, 2017 at 09:54:05PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 5:57 PM, Will Deacon wrote:
> > Do you reckon you can bisect between -rc1 and -rc2? We've been unable to
> > reproduce this o
On Tue, Dec 12, 2017 at 05:00:33PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven
> wrote:
> > On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon wrote:
> >> On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
> >
Hi Geert,
On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
> During userspace (Debian jessie NFS root) boot on arm64:
>
> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
> esr 0x9204, in dash[adf77000+1a000]
> CPU: 0 PID: 1083 Comm: rpcbind Not ta
ool of_iommu_driver_present(struct device_node
> *np)
>
> ops = iommu_ops_from_fwnode(fwnode);
> if ((ops && !ops->of_xlate) ||
> + !of_device_is_available(iommu_spec->np) ||
> (!ops && !of_iommu_driver_present(iommu_
On Mon, Feb 13, 2017 at 12:04:18PM +0100, Geert Uytterhoeven wrote:
> Some IOMMUs (e.g. Renesas IPMMU/VMSA) support only page sizes of 4 KiB,
> 2 MiB, and 1 GiB.
>
> With the default setting of CONFIG_CMA_ALIGNMENT = 8, allocations larger
> than 1 MiB are aligned to a 1 MiB boundary only. Hence a
On Tue, Jan 24, 2017 at 03:33:51PM +, Mark Rutland wrote:
> On Tue, Jan 24, 2017 at 04:30:19PM +0100, Geert Uytterhoeven wrote:
> > If CONFIG_DEBUG_VIRTUAL=y, during s2ram:
> >
> > virt_to_phys used for non-linear address: ff80085db280
> > (cpu_resume+0x0/0x20)
> > [ c
On Wed, Jan 11, 2017 at 11:11:17AM +0100, Geert Uytterhoeven wrote:
> From: Takeshi Kihara
>
> This patch adds support for DMA_ATTR_SKIP_CPU_SYNC attribute for
> dma_{un}map_{page,sg} functions family to swiotlb.
>
> DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
> the CP
On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
> >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> index 5ac373c..480b644 100644
> >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> +++ b/drivers/staging/fsl-mc/bus/fs
On Mon, Jan 09, 2017 at 10:30:02AM +0300, Nikita Yushchenko wrote:
> It is possible that device is capable of 64-bit DMA addresses, and
> device driver tries to set wide DMA mask, but bridge or bus used to
> connect device to the system can't handle wide addresses.
>
> With swiotlb, memory above 4
On Thu, Dec 29, 2016 at 11:45:03PM +0300, Nikita Yushchenko wrote:
> It is possible that PCI device supports 64-bit DMA addressing, and thus
> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
> bridge has limitations on inbound transactions addressing. Example of
> such setu
On Mon, Jul 04, 2016 at 02:48:08AM +, Peter Chen wrote:
> >Please route this via arm-soc once you've addressed Suzuki's comment.
>
> Hi Will, how to route patch via arm-soc?
>
> Does it mean sending patch by adding a...@kernel.org at To or Cc list?
Yes. I just wanted to make it clear that I
On Fri, Jul 01, 2016 at 11:29:58AM +0100, Suzuki K Poulose wrote:
> On 01/07/16 10:41, Peter Chen wrote:
> >of_node_put needs to be called when the device node which is got
> >from of_parse_phandle has finished using.
> >
> >Cc: Will Deacon
> >Cc: Suzuki K Poul
On Sun, May 08, 2016 at 12:59:56PM +0200, Niklas Söderlund wrote:
> The call to dma_sync_single_for_device() can be reached from
> dma_map_single(). If CONFIG_DMA_API_DEBUG is enabled this would result
> in a check that the mapping being synced is valid. Since the call to
> dma_map_single is not ye
24 matches
Mail list logo
