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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200917122703.ojuzn6b3tvqbnssc@akan>
Date:   Thu, 17 Sep 2020 07:27:03 -0500
From:   Nishanth Menon <nm@...com>
To:     Peter Rosin <peda@...ntia.se>
CC:     Roger Quadros <rogerq@...com>, <t-kristo@...com>,
        <robh+dt@...nel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <nsekhar@...com>,
        <kishon@...com>
Subject: Re: [PATCH v3 1/6] dt-bindings: mux-j7200-wiz: Add lane function
 defines

On 11:45-20200917, Peter Rosin wrote:
[...]
> 
> >> Should not the defines start with J7200_WIZ? SERDES0 seems like a too
> >> generic prefix, at least to me.
> > 
> > Thanks, good point. I am not sure if WIZ should even be used.. It is
> > a TI internal prefix for various serdes solutions, but I agree that
> > SERDES0 is too generic a terminology. That said, we should cleanup
> > include/dt-bindings/mux/mux-j721e-wiz.h as well, prior to introducing
> > j7200 changes.
> 
> Right. As maintainer for the directory in question, I should have
> been on Cc for that series too, but it appears I wasn't. Hence, I

yes, you should have been. The following commit introduced it.

commit b766e3b0d5f6 ("arm64: dts: ti: k3-j721e-main: Add system controller
node and SERDES lane mux")

> didn't notice that file until now when I went looking for it. Why
> wasn't I on Cc?

Got through the SoC tree - an oversight on our part[1] and should'nt have,
Apologies on the bad call.

I would like to propose the following:
a) The header should be renamed to be something more human friendly.
b) The header should be renamed to be something TI specific and NOT per
TI SoC.
c) The macros need renaming to be less generic as it stands right now.


If you ack the changes, I am guessing that the changes will impact dts
a lot and would rather take the cleanups through SoC tree to maintain
bisectability? OR I can pick on an immutable tag from you with just the
header file change and pick on the dts - but I doubt that would be
bisectable. Just worried that I have picked a bunch of cleanups already
on the dts for 5.10, and would like to avoid a merge conflict.


your thoughts?

[1] https://lore.kernel.org/linux-devicetree/20200709231933.GA1083562@bogus/

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ