linux-kernel - Re: Aw: Re: Re: [PATCH] arm64: dts: rockchip: Fix clocks for rk356x usb

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]

Message-ID: <CAMdYzYqQXnk=8Lc5ZeAPNQd-EGb=N61FM9r+E380mk6=Mvz1Tg@mail.gmail.com>
Date:   Sat, 9 Apr 2022 07:51:22 -0400
From:   Peter Geis <pgwipeout@...il.com>
To:     Heiko Stuebner <heiko@...ech.de>
Cc:     Dan Johansen <strit@...jaro.org>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Frank Wunderlich <linux@...web.de>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Michael Riesch <michael.riesch@...fvision.net>,
        devicetree <devicetree@...r.kernel.org>,
        arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Aw: Re: Re: [PATCH] arm64: dts: rockchip: Fix clocks for rk356x usb

On Sat, Apr 9, 2022 at 7:35 AM Heiko Stuebner <heiko@...ech.de> wrote:
>
> Am Samstag, 9. April 2022, 13:30:44 CEST schrieb Peter Geis:
> > On Sat, Apr 9, 2022 at 7:14 AM Peter Geis <pgwipeout@...il.com> wrote:
> > >
> > > On Sat, Apr 9, 2022 at 7:01 AM Heiko Stuebner <heiko@...ech.de> wrote:
> > > >
> > > > Am Samstag, 9. April 2022, 12:57:39 CEST schrieb Frank Wunderlich:
> > > > > Hi
> > > > > > Gesendet: Samstag, 09. April 2022 um 12:40 Uhr
> > > > > > Von: "Dan Johansen" <strit@...jaro.org>
> > > > >
> > > > > > So the issue is only with usb 3 ports, not usb 2 ports?
> > > > >
> > > > > my board has no standalone usb2-ports. usb2 is integrated into the usb3 ports (dual phy). here both were not working.
> > > > >
> > > > > afaik rk3566 has standalone usb2 ports that may not be broken, but i have no such board for testing.
> > >
> > > Good Morning,
> > >
> > > >
> > > > As far as I understand the issue now after checking the code, this
> > > > patch actually fixes the usb3 series from Peter, right?
> > > >
> > > > I.e. the usb-nodes that are fixed in this patch are not yet present
> > > > in the main rk356x dtsi and only get added in
> > > > "arm64: dts: rockchip: add rk356x dwc3 usb3 nodes" [0]
> > > >
> > > > As we don't want to add broken changes, this fix should squashed
> > > > into a next version of the patch adding the nodes.
> > >
> > > Thank you for reporting this, I will squash this fix in and add your signed-off.
> > >
> > > However the offending patch is in fact the clock separation patch, and
> > > it breaks backwards compatibility with the rk3328 dtsi which is why my
> > > series also is broken.
> > >
> > > The rockchip,dwc3.yaml needs to be fixed to align with the
> > > snps,dwc3.yaml, and both the rk3328 and rk3399 clock names updated.
> > > Also the offending clock separation patch needs a fix to grab the old
> > > clock names for rk3328 backwards compatibility to be retained.
> > >
> > > This might also be a good time to look into moving rk3399 to the core
> > > dwc3 driver?
> > >
> > > This is a delightful mess.
> >
> > In the idea of getting this series to land, if all parties agree, I'll
> > submit a patch that fixes the clock separation patch with this series
> > and leave the naming as is for now.
> > The renaming of clocks and alignment of everything can be addressed in
> > a future series once discussion on how best to handle it has happened.
> >
> > Do you concur with this?
>
> I'm not sure about that ... i.e. adding known-broken changes
> (for the rk356x) feels somewhat wrong to me.

My series as it is complies with the current dt-binding for Rockchip.
It just so happens the dt-binding describes two different devices that
are handled by two different drivers, and the binding itself was
wrong.
This becomes a whole lot more intrusive if we decide to do this now,
and the offending change still needs to be fixed if we want to retain
backwards compatibility with rk3328.dtsi

>
> Heiko
>
>