Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934034AbdCLJYL (ORCPT ); Sun, 12 Mar 2017 05:24:11 -0400 Received: from mail.kernel.org ([198.145.29.136]:45638 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933557AbdCLJYE (ORCPT ); Sun, 12 Mar 2017 05:24:04 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170309113311.15345-1-jh80.chung@samsung.com> <58C142F6.2030708@ti.com> From: Krzysztof Kozlowski Date: Sun, 12 Mar 2017 11:23:59 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] phy: samsung: move the Samsung specific phy files to "samsung" directory To: Vivek Gautam Cc: Kishon Vijay Abraham I , Jaehoon Chung , "linux-kernel@vger.kernel.org" , Kukjin Kim , kamil@wypas.org, Sylwester Nawrocki , Javier Martinez Canillas , inux-samsung-soc@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1253 Lines: 34 On Sun, Mar 12, 2017 at 11:18 AM, Vivek Gautam wrote: > Hi Kishon, > > > On Thu, Mar 9, 2017 at 5:26 PM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Thursday 09 March 2017 05:03 PM, Jaehoon Chung wrote: >>> Make the "samsung" directory and move the Samsung specific files to >>> there for maintaining the files relevant to Samsung. >> >> The number of phy drivers in drivers/phy is getting unmanageable. I think this >> is a good step to make it a little better. Can you also add a MAINTAINER for >> drivers/phy/samsung? > > I remember making a similar attempt in past [1], but that time we couldn't > reach an agreement as to whether group the phy drivers based on > vendors or based on the type of phy. > > If you are fine with grouping the drivers for each vendor, I hope you can > consider picking that patch (I can respin the patch based on linux-phy/next). > Other driver maintainers were also cool with that older patch. > > Let me know your comments. > > [1] https://patchwork.kernel.org/patch/8762561/ I am fine with the vendor approach. We follow this also for other sub-blocks, although usually they are strictly related to one type of device (e.g. clock controller). Best regards, Krzysztof