Re: [PATCH 2/2] iommu/io-pgtable-arm: use __dma_sync_single_for_device()

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

Re: [PATCH 4/7] bus: arm-cci: add missing of_node_put after calling of_parse_phandle

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 <will.dea...@ar

Re: [PATCH 4/7] bus: arm-cci: add missing of_node_put after calling of_parse_phandle

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

Re: [PATCH] drivers: firmware: psci: Use __pa_symbol for cpu_resume

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) > > [

Re: [PATCH/RESEND] arm64: defconfig: Enlarge CMA alignment to 2 MiB

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

Re: [PATCH] arm64: Add support for DMA_ATTR_SKIP_CPU_SYNC attribute to swiotlb

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

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

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

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

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

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

; > ops = iommu_ops_from_fwnode(fwnode); > if ((ops && !ops->of_xlate) || > + !of_device_is_available(iommu_spec->np) || > (!ops && !of_iommu_driver_present(iommu_spec->np))) > return NULL; Without this patch, v4.12-r

Re: arm64: unhandled level 0 translation fault

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 <will.dea...@arm.com> wrote: > > Do you reckon you can bisect between -rc1 and -rc2? We've been unable to > >

Re: arm64: unhandled level 0 translation fault

On Tue, Dec 12, 2017 at 05:00:33PM +0100, Geert Uytterhoeven wrote: > On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven > <ge...@linux-m68k.org> wrote: > > On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon <will.dea...@arm.com> wrote: > >> On Tue, Dec 12, 2017 at 11:

Re: arm64: unhandled level 0 translation fault

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

Re: arm64: unhandled level 0 translation fault

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: > > > >

Re: arm64: unhandled level 0 translation fault

On Fri, Dec 15, 2017 at 04:59:28PM +0100, Geert Uytterhoeven wrote: > On Fri, Dec 15, 2017 at 3:27 PM, Will Deacon <will.dea...@arm.com> 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 <

Re: arm64: unhandled level 0 translation fault

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

Re: [PATCH 37/61] perf: simplify getting .drvdata

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.

Re: [PATCHv2 6/8] arm_pmu: explicitly enable/disable SPIs at hotplug

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