From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932599AbcASCnb (ORCPT ); Mon, 18 Jan 2016 21:43:31 -0500 Received: from mailout2.samsung.com ([203.254.224.25]:39511 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932446AbcASCn1 (ORCPT ); Mon, 18 Jan 2016 21:43:27 -0500 MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=iso-8859-15 X-AuditID: cbfee691-f79766d0000012b6-48-569da2cd3def Date: Tue, 19 Jan 2016 11:43:16 +0900 From: Andi Shyti To: Yadwinder Singh Brar Cc: linux-samsung-soc , Sangbeom Kim , Krzysztof Kozlowski , Michael Turquette , Stephen Boyd , linux-kernel , linux-clk@vger.kernel.org, Andi Shyti Subject: Re: [PATCH 2/2] clk: s2mps11: allocate only one structure for clock init Message-id: <20160119024316.GA3793@samsunx.samsung> References: <1453105525-31506-1-git-send-email-andi.shyti@samsung.com> <1453105525-31506-3-git-send-email-andi.shyti@samsung.com> Content-transfer-encoding: 8bit In-reply-to: User-Agent: Mutt/1.5.24 (2015-08-30) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsWyRsSkQPfsorlhBot3clss/vGcyeL1C0OL jz33WC0u75rDZjHj/D4mi4unXC0urvjCZPHjTDeLxdzfjawOnB7vb7Sye1zu62XyuL7kE7PH zll32T36tqxi9Pi8SS6ALYrLJiU1J7MstUjfLoErY/7298wFLTwVTw98Zm5g7OHsYuTgkBAw kdi+UbeLkRPIFJO4cG89WxcjF4eQwApGibfz5rBBJEwkph1YwAyRmMUocebjXnaQBK+AoMSP yfdYQGxmAWmJR39nsIMMZRbQlViwwQOi/iPQoIlPwGpYBFQl2ia/Zwax2QQ0JZpu/wBbICJg IDFxyTxWkAZmgYtMEqueXAYbJCwQLLH9ZDzELmOJdd8eM0IMPcUocXbHI3aIxfISB688B1vA CVTfv+k8I0ivqICKxKuD9SD1EgI/2SV279zOCHGEgMS3yYdYIL6Xldh0gBniSUmJgytusExg FJ+F5LVZSF6bhfDaLCSLFzCyrGIUTS1ILihOSi8y1StOzC0uzUvXS87P3cQIjN7T/55N3MF4 /4D1IUYBDkYlHt4J9nPDhFgTy4orcw8xmgIdNJFZSjQ5H5gi8kriDY3NjCxMTUyNjcwtzZTE eXWkfwYLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFy1ucZm19O01vlvFnhPy6k51if8I/PI gki2b776H0VvBLyrrHin4PPgQP2veYXTOtvalvTuvuUkomPVeb1HsurrAa0iy+0mHQ4vjRaY eet0ngvnaXvye9vrzm+nzPZ/mMuhaycd6DjxU6risbXFzQf1LBKmqN0ynyY2fdt0xulSnppW IfeZFymxFGckGmoxFxUnAgDX24j42QIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsVy+t9jQd2zi+aGGZxcxGax+MdzJovXLwwt PvbcY7W4vGsOm8WM8/uYLC6ecrW4uOILk8WPM90sFnN/N7I6cHq8v9HK7nG5r5fJ4/qST8we O2fdZffo27KK0ePzJrkAtqgGRpuM1MSU1CKF1Lzk/JTMvHRbJe/geOd4UzMDQ11DSwtzJYW8 xNxUWyUXnwBdt8wcoKOUFMoSc0qBQgGJxcVK+naYJoSGuOlawDRG6PqGBMH1GBmggYQ1jBnz t79nLmjhqXh64DNzA2MPZxcjJ4eEgInEtAMLmCFsMYkL99azdTFycQgJzGKUOPNxLztIgldA UOLH5HssIDazgLTEo78zgOIcQLauxIINHhD1Hxkl3k58AlbDIqAq0Tb5PdhQNgFNiabbP9hA bBEBA4mJS+axgjQwC1xkklj15DLYIGGBYIntJ+MhdhlLrPv2mBFi6ClGibM7HrFDLJaXOHjl OdgCTqD6/k3nGUF6RQVUJF4drJ/AKDgLyamzkJw6C+HUWUgGLWBkWcUokVqQXFCclJ5rlJda rlecmFtcmpeul5yfu4kRnCKeSe9gPLzL/RCjAAejEg/vBPu5YUKsiWXFlbmHGCU4mJVEeCfM BwrxpiRWVqUW5ccXleakFh9iNAWGwURmKdHkfGD6yiuJNzQ2MTOyNDI3tDAyNlcS5913KTJM SCA9sSQ1OzW1ILUIpo+Jg1OqgXH/KcXHfSfvaktzaRkJ8veUBEpVfZUruSyRKqlcFvJ8y9L3 qTe+mLyL3XTtzhvDnfVe+x8cfMnTc1P/8PxKk/PXZ8hOsND7eJiv+mLqQtFndpXS1t+3pB10 sNl0kGVt1SbGf8dNVm2JUp3w45jT063nQy/9n1H1uWBioJz0HcEPqf2z7B7Ee2xSYinOSDTU Yi4qTgQA0U8MmycDAAA= 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 Hi Yadwinder, > The driver allocates three structures for three different clock > types. They are quite similar and in the clock init data they > differ only by the name. Only one of these structure is used, > while the others lie unused in the memory. > > > If you are worried about memory, they can be made __initdata by > creating a copy during probe. mmmhhh... allocating in boot time as much as we want and then copy what we need? It doesn't look that pretty to me. > The clock's name, though, is not such a meaningful information > > > I think it can be meaningful in debugging. Can you explain what's the use of the naming other than debugging? > and by assigning the same name to the initial data we can avoid > over allocation. The common name chosen will be s2mps11, > coherently with the device driver name, instead of the clock > device. > > Therefore, remove the structures associated to s2mps13 and > s2mps14 and use only the one referred to s2mps11 for all kind of > clocks. > > > IMHO, with all these modifications, it will leave driver with some extra > checks and reduced readability, perhaps will make it complex to add > support for similar clocks but with different clk_ops, if next version or >  any similar mfd chip comes up in future. In that case, when the new chip will come, we would need to figure out something, but for sure I don't see it as a good idea to leave allocated unused structures. Thanks, Andi