linux-kernel - Re: [PATCH 3/4] phy: rockchip-typec: support DP phy switch

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, 9 Mar 2017 15:35:06 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Heiko Stübner <heiko@...ech.de>
Cc:     Chris Zhong <zyw@...k-chips.com>, dri-devel@...ts.freedesktop.org,
        kishon@...com, robh@...nel.org, linux-rockchip@...ts.infradead.org,
        linux-kernel@...r.kernel.org, seanpaul@...omium.org,
        groeck@...omium.org, linux-arm-kernel@...ts.infradead.org,
        mark.yao@...k-chips.com, Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH 3/4] phy: rockchip-typec: support DP phy switch

On Thu, Mar 09, 2017 at 09:31:33AM +0100, Heiko Stuebner wrote:
> Am Mittwoch, 8. März 2017, 19:10:50 CET schrieb Brian Norris:
> > Another random point of contention (not worth too much, as the pattern
> > is already set), but why do these deserve DT properties at all? The
> > device already has a "rk3399" compatible property, so can't we derive
> > GRF offsets from that?
> 
> I'm definitly with you in this regard.
> 
> But it seems like there is some sort of current trend of moving more stuff 
> into the dt again. I vaguely remember phy and (or) dt-maintainers preferring 
> to have these definitions in the dt for the typec-phy.

Hmm, not sure I understand that one. You're just going to multiply the
variations of DT props you have to support, instead of simply
multiplying a (non-ABI) table within the driver. The latter seems much
more stable. Oh well, not my subsystem.

> See also the recent mail from Olof concerning the grf initialization and maybe 
> not having per-soc definitions in the driver, where I'm trying to keep things 
> out of the dt a bit more strongly :-) .

Thanks for the pointer. I looked up (and replied to) that one.

Either I don't understand exactly what he's saying or... I'd like to
know what he's smoking. You can't just wish away the fact that the GRF
is truly a "general register file" and will change forever (and so will
our understanding of how to use it). Kernels always need to update for
new chipsets. Device Tree Bindings Are Forever (TM).

Now let's see if Olof reads my reply which points back to this
thread...and now to the above comment :)

> So yes, personally I would definitly prefer not having to much GRF-stuff leak 
> into the dt. Simply because the GRF has always been very unstable over time 
> [=you always find one more bit that needs tuning] and to not cause things like 
> the above. But as you said I guess we're to late for the typec-phy.

I'm with you.

Brian