[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a12yH0yowpJdn6GRVOnOnnugwBewrYyDHDmBNv-RE6Qjw@mail.gmail.com>
Date: Wed, 31 May 2017 12:25:20 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Kishon Vijay Abraham I <kishon@...com>,
Yuvaraj Kumar C D <yuvaraj.cd@...il.com>,
Girish K S <ks.giri@...sung.com>,
Vasanth Ananthan <vasanth.a@...sung.com>,
Jaehoon Chung <jh80.chung@...sung.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PHY: Exynos: fix I2C dependency for Exynos5250 SATA
On Wed, May 31, 2017 at 12:12 PM, Krzysztof Kozlowski <krzk@...nel.org> wrote:
> On Tue, May 30, 2017 at 11:28 AM, Arnd Bergmann <arnd@...db.de> wrote:
>> Device drivers should not 'select' other subsystems, but rather use
>> 'depends on', to avoid Kconfig dependency loops. This one even
>> selects a particular I2C host driver for no reason, so we can
>> remove the select of that particular driver, and turn the I2C
>> 'select' into 'depends on'.
>>
>> Fixes: bcff4cba41bc ("PHY: Exynos: Add Exynos5250 SATA PHY driver")
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>> ---
>> drivers/phy/samsung/Kconfig | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/samsung/Kconfig b/drivers/phy/samsung/Kconfig
>> index b7e0645a7bd9..76475b01780d 100644
>> --- a/drivers/phy/samsung/Kconfig
>> +++ b/drivers/phy/samsung/Kconfig
>> @@ -83,10 +83,9 @@ config PHY_EXYNOS5250_SATA
>> tristate "Exynos5250 Sata SerDes/PHY driver"
>> depends on SOC_EXYNOS5250
>> depends on HAS_IOMEM
>> + depends on I2C
>> depends on OF
>> select GENERIC_PHY
>> - select I2C
>> - select I2C_S3C2410
>> select MFD_SYSCON
>> help
>> Enable this to support SATA SerDes/Phy found on Samsung's
>
> I think this effectively might disable the I2C_S3C2410 on
> exynos_defconfig. Previously, the defconfig chosen PHY_EXYNOS5250_SATA
> which selected the I2C_S3C2410. Now the I2C_S3C2410 will remain
> forgotten.
Good point. I only checked that CONFIG_I2C was still enabled, but
didn't consider the specific driver.
> BTW, It might be also useful to do similar for EXTCON and PHY_ROCKCHIP_TYPEC.
Right. We have more problems like this, I was planning to see where I
got with the I2C ones first, but that is another one I had not noticed yet.
Arnd
Powered by blists - more mailing lists