From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752619AbbJEIYT (ORCPT ); Mon, 5 Oct 2015 04:24:19 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:56623 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752441AbbJEIYO (ORCPT ); Mon, 5 Oct 2015 04:24:14 -0400 X-AuditID: cbfee691-f79d66d000001509-9d-561233ac3880 Message-id: <56123165.2060500@samsung.com> Date: Mon, 05 Oct 2015 13:44:29 +0530 From: Alim Akhtar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-version: 1.0 To: Arnd Bergmann , kbuild test robot Cc: kbuild-all@01.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, JBottomley@odin.com, vinholikatti@gmail.com, amit.daniel@samsung.com, essuuj@gmail.com, devicetree@vger.kernel.org, Rob Herring Subject: Re: [PATCH v3 13/13] scsi: ufs: Add exynos ufs platform data References: <201510011845.GN7Kisc4%fengguang.wu@intel.com> <1790578.NZeHVGuJeN@wuerfel> In-reply-to: <1790578.NZeHVGuJeN@wuerfel> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsWyRsSkWneNsVCYwcR7YhYNV0Ms/k46xm4x /8g5VovlF5YwWfxff5vF4tj1icwWl3fNYbPovr6DzeJV8yM2i/97drBb7FhY5cDtcX8vu8fv X5MYPXbOusvusXjPSyaPTas62TwO//jB7NG3ZRWjx+dNcgEcUVw2Kak5mWWpRfp2CVwZ/Zeb WAqucVdseniCtYFxAWcXIyeHhICJxKLLSxghbDGJC/fWs4HYQgIrGCWeXg6DqdnT/py5i5EL KD6LUeJK+wxWCOcBo8SU6feZQap4BbQkfs4/CGazCKhKvN78Amwqm4C2xN3pW5i6GDk4RAUi JB5fEIIoF5T4MfkeC4gtIuAi8eTqCUaQmcwCLxglmnZOYwdJCAu4SvxYu5kF4qJIiV9T+8Hm cwpoShy9sBVsPrOAtcTKSdugbHmJzWvegl0qIdDKIXF+5kQ2iIMEJL5NPsQCcoSEgKzEpgPM EJ9JShxccYNlAqPYLCQ3zUIydhaSsQsYmVcxiqYWJBcUJ6UXmeoVJ+YWl+al6yXn525iBMbt 6X/PJu5gvH/A+hCjAAejEg+vRJJgmBBrYllxZe4hRlOgKyYyS4km5wOTQ15JvKGxmZGFqYmp sZG5pZmSOK+O9M9gIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYy9uivdckIZq+e9+FaRs4w7 6cNP88KU86ePmcpu0bhUULX0FN/fy7nSpsrv79TvktogLhmwJ9V6Opeyrzu3Y2Ijx8sqcfHf TQERS/v2NcX69u+p3vzYQ1zOtEu3tF7R/rN46y6TkOMZKc9rGlmrnJju/PCben/jP4l3RrnF Jy5P3dp23GWypBJLcUaioRZzUXEiABy50R7WAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsVy+t9jQd01xkJhBmfv81k0XA2x+DvpGLvF /CPnWC2WX1jCZPF//W0Wi2PXJzJbXN41h82i+/oONotXzY/YLP7v2cFusWNhlQO3x/297B6/ f01i9Ng56y67x+I9L5k8Nq3qZPM4/OMHs0ffllWMHp83yQVwRDUw2mSkJqakFimk5iXnp2Tm pdsqeQfHO8ebmhkY6hpaWpgrKeQl5qbaKrn4BOi6ZeYA3amkUJaYUwoUCkgsLlbSt8M0ITTE TdcCpjFC1zckCK7HyAANJKxhzOi/3MRScI27YtPDE6wNjAs4uxg5OSQETCT2tD9nhrDFJC7c W8/WxcjFISQwi1HiSvsMVgjnAaPElOn3wap4BbQkfs4/CGazCKhKvN78ghHEZhPQlrg7fQtT FyMHh6hAhMTjC0IQ5YISPybfYwGxRQRcJJ5cPcEIMpNZ4AWjRNPOaewgCWEBV4kfazeDFQkJ REr8mtoPNp9TQFPi6IWtYPOZBawlVk7aBmXLS2xe85Z5AiPQmQg7ZiEpm4WkbAEj8ypGidSC 5ILipPRco7zUcr3ixNzi0rx0veT83E2M4OTwTHoH4+Fd7ocYBTgYlXh4D8QLhgmxJpYVV+Ye YpTgYFYS4dXWEgoT4k1JrKxKLcqPLyrNSS0+xGgKDISJzFKiyfnAxJVXEm9obGJuamxqaWJh YmapJM574xBDmJBAemJJanZqakFqEUwfEwenFDBZsO88MW/q3WlVgU3H9m2/ueRhZW5c3d+b poLzODvj99Z98k/oii3479cfMd3hrrVwTMjNSC9v4eT04wrmBWkFdhPzp78Jq3PwSP/g9XRd Wc7+iNaLb1dWneu5dmXBQUv3pBfnrz7J1jCt27zrxbqu27a8tiURr0Jir8oKHL4qnae7vNnh 5gIlluKMREMt5qLiRAA/NT25JAMAAA== 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 CCing Rob Herring, Hi Arnd, On 10/01/2015 04:59 PM, Arnd Bergmann wrote: > On Thursday 01 October 2015 18:46:34 kbuild test robot wrote: >> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] >> >> config: x86_64-allmodconfig (attached as .config) >> reproduce: >> git checkout 6e153e3bf7c68b019e987c5a0ffadebd9c7d4fbb >> # save the attached .config to linux build tree >> make ARCH=x86_64 >> >> All error/warnings (new ones prefixed by >>): >> >>>> ERROR: "ufs_hba_exynos_ops" [drivers/scsi/ufs/ufshcd-pltfrm.ko] undefined! >> >> > > Ah, this seems to be a case of layering violation. It would be best to > restructure the code so that the exynos driver registers a platform_driver > by itself for the respective DT compatible string, and then calls > into the common code from its probe function, rather than having the > generic driver know about the specific backends. > > That approach will also make the generic driver more scalable as we > add further chip-specific variations, and matches what we do in other > drivers. > Looks like some discussions on ufs variant driver probe method happened here [1] few months back. [1]-> https://lkml.org/lkml/2015/6/3/180 And since ufshcd-pltfrm is already a platform_driver, so I just add a platform data for the variant driver. I should have add a IS_ENABLED for it to avoid the compilation error for other ARCH. Thanks!! > Arnd >