From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932255AbcFCIm6 (ORCPT ); Fri, 3 Jun 2016 04:42:58 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:61404 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751544AbcFCImz (ORCPT ); Fri, 3 Jun 2016 04:42:55 -0400 From: Arnd Bergmann To: Eric Anholt Cc: Gerd Hoffmann , linux-rpi-kernel@lists.infradead.org, Ulf Hansson , Stephen Warren , Lee Jones , open list , "open list:MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND..." , "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" Subject: Re: [PATCH 21/32] mmc: bcm2835-sdhost: Add new driver for the internal SD controller. Date: Fri, 03 Jun 2016 10:42:59 +0200 Message-ID: <5371567.ZLhe0cdM9e@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <87vb1ra295.fsf@eliezer.anholt.net> References: <1464817421-8519-1-git-send-email-kraxel@redhat.com> <4715245.LFBOAeJdHc@wuerfel> <87vb1ra295.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:WpEnpuJMj3okH33DFeY6gdhpEnr+cUusgL/Oo6R9olO4j0O64qQ +Q6JmFzbJ79HvfAx8jF5++xdBFrhiVjhOBJDUfNJsVB88fPgD/CoylDg/sHnBCZbN9+t/03 GEG3OtLodH6nKQmAsIE/tshf8zDqb+jT8NO/+rjOrO+hIpy2GO2CoRg0PmNUxk7nZiyeT9r /OQJg/Gq0cxDAF8abi5Ww== X-UI-Out-Filterresults: notjunk:1;V01:K0:mK3EL7X1f/k=:RZlbHxYqHTYZN9aVYwCrQC VBGJcvKOKX6vOHQ+fJlyW9vOugXmpl8Eo/zChWDbyNqE6vrcINGcgCzWud4qf+QlB93wvOEsC PAptrOZtrRE3F1aK/WyYB6POisnnSykg7Ow8knONgPMPLxRZGidNCMtsz9DF0CcD7GrplJSnG cYJgU369HY/gwsSZTp7jhh4TaFpJubUt+sUT3d2QKafvKV0pHiWynTaXU0HMlcfrK9x2kh1F/ NqBwwyx92uIx3SaK5yinmad08hVk9UgSR2/M1bLiQZBrjJbFkniDpSvFghr1FuVAnggaOnT3S lOcFOc5eDdtOlGzo2bHH6EC14D5D7QMKCEKLSN85fDBDr0Wz4Y45CHwrnseKW1KI6yo3yjIGh QdOYtovatiFo3N1bHpjUJKOYYvXnVACMp3/Nz2mZEoYVVrC9gD9fxnCI7B2PVhfI77CDHKeYH k3LMyzQHmo+y6eESMQabDQ5v5BhaYS1BqjZmBIh1dILChFtm4s7Ps2815OV0phKUms5wwPJnJ +7Qhy7U7YfpTfqb+uWm1cvZrKND1aaPugvBs02e6jytT+0Fj/kx+xszJnnGdAjKN2OplEmtEu AYWSp8KrSehy4GrVqe+nqjeXQgmDwon7aJiZcHBw3Jhd49Uq6nPNnSba2msjr7Dt1ss5/W89R AQklh/Y0yBUVPAPZfiL+1Y3vn4LLYiyqojM1c/9L+obaKpZ3GbrhQSzL+BiYzD5ajfQ3ckRyX /O2SEA/YctLDf/hS Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, June 2, 2016 11:12:38 AM CEST Eric Anholt wrote: > Arnd Bergmann writes: > > > On Wednesday, June 1, 2016 11:43:30 PM CEST Gerd Hoffmann wrote: > >> + /* Parse OF address directly to get the physical address for > >> + * DMA to our registers. > >> + */ > >> + host->phys_addr = be32_to_cpup(of_get_address(pdev->dev.of_node, 0, > >> + NULL, NULL)); > > > > This looks broken on 64-bit systems when #address-cells=<2>, or if there > > is an intermediate bus with a non-empty ranges property. > > > > What's wrong with platform_get_resource(pdev, IORESOURCE_MEM, 0)? > > I'll get to the rest of the review later, but this is a weird pattern > that we have in several bcm2835-related drivers. > > We need the address as seen by the DMA controller, not the address from > the ARM's perspective (which is offset by the dma-ranges DT property). > This is the way that people have figured out to get that address. I see. This is indeed a bit tricky, as there is no easy way to know how the dmaengine is wired up to the slave. A correct solution is probably to follow the 'dma-ranges' up from the master to the common parent and then follow the 'ranges' back to the slave, but that requires coming up with a new exported function. It's perhaps good enough in the meantime to read out the address from the slave directly, but you should not assume that the first cell has the complete information and instead should at least evaluate #address-cells. Arnd