From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965227AbbJVJTy (ORCPT ); Thu, 22 Oct 2015 05:19:54 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:21761 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965209AbbJVJTp (ORCPT ); Thu, 22 Oct 2015 05:19:45 -0400 X-AuditID: cbfec7f5-f794b6d000001495-ce-5628aa2d0235 Subject: Re: [PATCH v2 1/3] dt-bindings: Consolidate SRAM bindings from all vendors To: Maxime Ripard References: <1445477130-407-1-git-send-email-k.kozlowski@samsung.com> <20151022090529.GV10947@lukather> Cc: Kukjin Kim , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Javier Martinez Canillas , Heiko Stuebner , Chen-Yu Tsai From: Krzysztof Kozlowski X-Enigmail-Draft-Status: N1110 Message-id: <5628AA23.5070608@samsung.com> Date: Thu, 22 Oct 2015 18:19:31 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-version: 1.0 In-reply-to: <20151022090529.GV10947@lukather> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsVy+t/xy7q6qzTCDB4cVLGYf+Qcq0X/m4Ws Fv8fvWa1OPdqJaPFm7drmCxevzC06H/8mtli0+NrrBaXd81hs/j04D+zxYzz+5gsll6/yGSx ddNeZosJ09eyWLTuPcJu8fPQeSYHAY8189Ywelzu62Xy2PBoNavHk00XGT1WLv/C5rFpVSeb x+Yl9R5b+u+ye/RtWcXosf3aPGaPz5vkArijuGxSUnMyy1KL9O0SuDK2/ZrMWHBNpOLb8S7G BsYewS5GTg4JAROJ2zdOs0PYYhIX7q1n62Lk4hASWMoocePJGTaQhJDAF0aJX7NMQWxhgVCJ TQcXsYLYIkDNT9a9YYeoyZQ4cGwuE0gzs0ATi0THlfdgRWwCxhKbly9hg9ggJ9HbPYkFxOYV 0JJ4cPc5M4jNIqAqsXvGUjBbVCBCYuKEBlaIGkGJH5PvgdVzCuhJHNmzDqiGA2iBnsT9i1og YWYBeYnNa94yT2AUnIWkYxZC1SwkVQsYmVcxiqaWJhcUJ6XnGukVJ+YWl+al6yXn525ihETj 1x2MS49ZHWIU4GBU4uHV+K8eJsSaWFZcmXuIUYKDWUmE99JUjTAh3pTEyqrUovz4otKc1OJD jNIcLErivDN3vQ8REkhPLEnNTk0tSC2CyTJxcEo1MIaZ8jMUK15a6r/v98fIerk9JhxCc924 71cHLX673pldr3WO+c9zaab1bSbpiodZnlb2Hl4YZyM4z8vi5IPGt196pn1oq7fKX7nZu07e L+D/u2OWphFLvX9+y05m/JIf1JGxsosp9vA3V5tVb+6ySqQwywYHq/s/jg0RfsssI/fjycI5 Oz3/K7EUZyQaajEXFScCAMmxwvfCAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22.10.2015 18:05, Maxime Ripard wrote: > Hi, > > On Thu, Oct 22, 2015 at 10:25:28AM +0900, Krzysztof Kozlowski wrote: >> SRAM bindings for various SoCs, using the mmio-sram genalloc >> API, are spread over different places - per SoC vendor. Since all of >> these are quite similar (they depend on mmio-sram) move them to a common >> place. >> >> Signed-off-by: Krzysztof Kozlowski >> Cc: Heiko Stuebner >> Cc: Maxime Ripard >> Cc: Chen-Yu Tsai >> Cc: Kukjin Kim >> Suggested-by: Rob Herring >> >> --- >> >> Changes since v1: >> 1. New patch. Extended suggestion from Rob. >> --- >> .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt} | 0 >> .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt} | 0 >> .../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt} | 0 >> Documentation/devicetree/bindings/{misc => sram}/sram.txt | 0 >> .../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} | 0 >> 5 files changed, 0 insertions(+), 0 deletions(-) >> rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt} (100%) >> rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt} (100%) >> rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt} (100%) >> rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%) >> rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} (100%) > > I'm not sure about that one. The SRAM bindins we have for sunxi is for > an SRAM controller, that maps the SRAM either to the CPU or to the > devices. > > It's not really related to the other users, and wouldn't it be > confusing to have a driver in drivers/soc, and a Documentation in > another sub-directory? I guess the only relation to other users is the "mmio-sram". In the same time this is still similar to e.g. Samsung's sram bindings (where the memory is mapped to CPU only). Being located in drivers/soc is not an issue here - code for other vendors may be moved there as well in the future. Of course I do not insist. Actually Rob's comment was only about moving sram.txt and Samsung's sram to common place. Anyway I will be sending v3 of these because while looking more carefully I found hard-coded paths to bindings/misc/sram.txt. I'll fix it in next version. Best regards, Krzysztof