linux-kernel - Re: [RFC PATCH 2/2] phy: phy-rockchip-inno-usb2: remove support for rockchip, rk3366-usb2phy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 19 Mar 2020 15:01:20 +0100
From:   Johan Jonker <jbx6244@...il.com>
To:     Robin Murphy <robin.murphy@....com>, kishon@...com
Cc:     devicetree@...r.kernel.org, heiko@...ech.de,
        linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
        robh+dt@...nel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 2/2] phy: phy-rockchip-inno-usb2: remove support for
 rockchip, rk3366-usb2phy

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.