From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932351AbbKRANT (ORCPT ); Tue, 17 Nov 2015 19:13:19 -0500 Received: from mailout4.samsung.com ([203.254.224.34]:41892 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754286AbbKRANR (ORCPT ); Tue, 17 Nov 2015 19:13:17 -0500 X-AuditID: cbfee68d-f79ae6d00000149a-0f-564bc29a3e51 Message-id: <564BC29A.9010306@samsung.com> Date: Wed, 18 Nov 2015 09:13:14 +0900 From: Jaehoon Chung User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-version: 1.0 To: Arnd Bergmann , Andy Shevchenko Cc: Ulf Hansson , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-arm Mailing List Subject: Re: [PATCH] mmc: dw_mmc: use resource_size_t to store physical address References: <28102387.ALpaBHpim0@wuerfel> <6288847.N1QBIiXedG@wuerfel> In-reply-to: <6288847.N1QBIiXedG@wuerfel> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsWyRsSkRHfWIe8wg2fbLC1eTjjMaPF30jF2 i02Pr7FaXN41h83iyP9+Rovja8Md2Dx+/5rE6LFz1l12jzvX9rB5bF5S7/F5k1wAaxSXTUpq TmZZapG+XQJXxoz1i9kLNgtVdF1bztjAOIevi5GTQ0LARGLHnUusELaYxIV769m6GLk4hARW MEocvrCeFaZoQuMUVojELEaJCfs2QDkPGCXeP1zMBlLFK6Al8WjhHbAOFgFViSOLNjKB2GwC OhLbvx0Hs0UFwiQerNvLClEvKPFj8j0WEFtEwE/i/7NZYDXMAk8ZJeZ2BYPYwgL+Eos2T2KH WNbPKHFoA8RQTgFNiZO/eoFsDqAGPYn7F7UgeuUlNq95ywxSLyFwjF3ib9sBNoiDBCS+TT7E AlIvISArsekAM8RnkhIHV9xgmcAoNgvJSbMQps5CMnUBI/MqRtHUguSC4qT0IkO94sTc4tK8 dL3k/NxNjMBIO/3vWe8OxtsHrA8xCnAwKvHwJiz2DhNiTSwrrsw9xGgKdMREZinR5HxgPOeV xBsamxlZmJqYGhuZW5opifMqSv0MFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCYqubnsaGW 9cGCNsP4mo8HZjGtOzTt3poX2mqH31qKsNs4xuQtUZ/JkOMv/UyR4Zm/+lutg48a/xYEbdus J82VJ5B/SsQ5ns3Q4MefNAaVosbIHL/6dawM+XGiKyONXuxmUX06Tbpd+lOCy14JTmWnac5v W3dJnoqT+jDVYpLZ/lIjm4sn5yixFGckGmoxFxUnAgDql2qUrwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsVy+t9jQd1Zh7zDDJZ8MrR4OeEwo8XfScfY LTY9vsZqcXnXHDaLI//7GS2Orw13YPP4/WsSo8fOWXfZPe5c28PmsXlJvcfnTXIBrFENjDYZ qYkpqUUKqXnJ+SmZeem2St7B8c7xpmYGhrqGlhbmSgp5ibmptkouPgG6bpk5QAcoKZQl5pQC hQISi4uV9O0wTQgNcdO1gGmM0PUNCYLrMTJAAwlrGDNmrF/MXrBZqKLr2nLGBsY5fF2MnBwS AiYSExqnsELYYhIX7q1n62Lk4hASmMUoMWHfBlYI5wGjxPuHi9lAqngFtCQeLbwD1sEioCpx ZNFGJhCbTUBHYvu342C2qECYxIN1e1kh6gUlfky+xwJiiwj4Sfx/NgushlngKaPE3K5gEFtY wF9i0eZJ7BDL+hklDm2AGMopoClx8lcvkM0B1KAncf+iFkSvvMTmNW+ZJzACnYmwYhZC1Swk VQsYmVcxSqQWJBcUJ6XnGuallusVJ+YWl+al6yXn525iBEfzM6kdjAd3uR9iFOBgVOLh5Vjo HSbEmlhWXJl7iFGCg1lJhJfTCijEm5JYWZValB9fVJqTWnyI0RQYBhOZpUST84GJJq8k3tDY xMzI0sjc0MLI2FxJnFff0yhMSCA9sSQ1OzW1ILUIpo+Jg1OqgbG0Uloz4GmV74wNfGVSagcP hfavu76k/tezX3dPJbQ8tZBs9lgh9mEXm452Zd5Lrth2hfSkJ83Hrhp4598PZJZn1l/RFNN8 r2mvJLd+2pIX+fwZR6JW9wWGP3nNzyDZK73wapn7rns3X5qs8Dzy4MeiS9dcTjp+OrH1qM+Z 6QFGh12vWd83YVBiKc5INNRiLipOBACrett//AIAAA== DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear, Arnd. On 11/13/2015 06:35 PM, Arnd Bergmann wrote: > On Friday 13 November 2015 03:10:13 Andy Shevchenko wrote: >> On Thu, Nov 12, 2015 at 4:14 PM, Arnd Bergmann wrote: >>> The dw_mmc driver stores the physical address of the MMIO registers >>> in a pointer, which requires the use of type casts, and is actually >>> broken if anyone ever has this device on a 32-bit SoC in registers >>> above 4GB. Gcc warns about this possibility when the driver is built >>> with ARM LPAE enabled: >> >>> - host->phy_regs = (void *)(regs->start); >>> + host->phy_regs = regs->start; >> >>> /* Set external dma config: burst size, burst width */ >>> - cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset); >>> + cfg.dst_addr = host->phy_regs + fifo_offset; >> >> dst_addr is dma_addr_t? > > Sort of. It doesn't really fit into any of the categories, and we actually > had a patch to change the type in the past, see > https://lkml.org/lkml/2015/7/10/167. Not sure what is going on there. why isn't the patch applied on mainline yet? :) Best Regards, Jaehoon Chung > >>> /* Registers's physical base address */ >>> - void *phy_regs; >>> + resource_size_t phy_regs; >> >> If dst_addr is dma_addr_t wouldn't be a problem when >> resource_size_t is defined as 64-bit address, and dma_addr_t as 32-bit? >> >> Btw, for me casting to dma_addr_t looks sane. > > The background here is that the address comes from a resource_size_t > that describes the MMIO register area as seen from the CPU, and that > is normally a phys_addr_t (resource_size_t is defined as being long > enough to store a phys_addr_t or various other things depending on > resource->flags). > > dma_addr_t strictly speaking refers to a RAM location as seen by a > DMA master, and that only comes out of dma_map_*() or > dma_alloc_coherent(). > > The DMA engine wants something else here, which is an MMIO register > address as seen by a DMA master, and we don't have a separate typedef > for that. Almost universally all of resource_size_t, phys_addr_t and > dma_addr_t are the same type, and if we ever get a platform that > wants something other than a phys_addr_t to put into cfg.dst_addr, > we are in deep trouble. > > Arnd >