Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC PATCH 2/2] phy: phy-rockchip-inno-usb2: remove support for
 rockchip, rk3366-usb2phy
To:     Robin Murphy <robin.murphy@arm.com>, kishon@ti.com
Cc:     devicetree@vger.kernel.org, heiko@sntech.de,
        linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
        robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org
References: <20200318192901.5023-1-jbx6244@gmail.com>
 <20200318192901.5023-2-jbx6244@gmail.com>
 <233769c3-a44a-0ebd-7a2c-6fab17fb56f2@arm.com>
From:   Johan Jonker <jbx6244@gmail.com>
Message-ID: <625d2904-458b-1edc-d91c-21614653a274@gmail.com>
Date:   Thu, 19 Mar 2020 15:01:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <233769c3-a44a-0ebd-7a2c-6fab17fb56f2@arm.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

Some questions.
Can Rockchip or Heiko explain why we have half finished support in the
upstream kernel for rk3366? What happened?
Are any plans to add a rk3366.dtsi?
How wide spread was the use of rk3366? Products?
ie. When does support stop?

There's also a rk3368. Is there a need for "rockchip,rk3368-usb2phy"?

We'll keep "rockchip,rk3366-usb2phy" aboard for v2.

Thanks

On 3/19/20 2:07 PM, Robin Murphy wrote:
> Hi Johan,
> 
> On 2020-03-18 7:29 pm, Johan Jonker wrote:
>> 'phy-rockchip-inno-usb2.txt' is updated to yaml, whereby
>> the compatible string 'rockchip,rk3366-usb2phy' was removed,
>> because it's not in use by a dts file, so remove support
>> in the code as well.
> 
> Here's a DT using it:
> 
> https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm64/boot/dts/rockchip/rk3366.dtsi#L820
> 
> 
> Please note that although DT bindings happen to be primarily maintained
> in the upstream kernel tree at the moment, it is mostly as a consequence
> of Linux being the source of most active development. Bindings should
> not be considered to be "owned" by upstream Linux since there are many
> other consumers, both downstream, and in completely different projects
> like the BSDs. As far as I'm aware there is still a long-term plan to
> eventually flip the switch and move maintenance to a standalone repo:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> 
> 
> Things like PCI Device IDs and ACPI HIDs aren't even documented as
> formally as DT bindings, so by the reasoning here we could arguably
> delete the majority of drivers from the kernel...
> 
> Robin.