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: <20190718194131.GK25635@lunn.ch>
Date:   Thu, 18 Jul 2019 21:41:31 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Sven Van Asbroeck <thesven73@...il.com>
Cc:     Fabio Estevam <festevam@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Fugang Duan <fugang.duan@....com>,
        "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: fec: generate warning when using deprecated phy
 reset

On Thu, Jul 18, 2019 at 01:21:36PM -0400, Sven Van Asbroeck wrote:
> Lucas, Fabio,
> 
> On Thu, Jul 18, 2019 at 12:52 PM Fabio Estevam <festevam@...il.com> wrote:
> >
> > > Not really a fan of this. This will cause existing DTs, which are
> > > provided by the firmware in an ideal world and may not change at the
> > > same rate as the kernel, to generate a warning with new kernels. Not
> > > really helpful from the user experience point of view.
> >
> > I agree. I don't think this warning is useful.
> 
> Few users watch the dmesg log, But I totally see your point.
> 
> The problem I'm trying to address here is this: when I want to
> reset the fec phy, I go look at existing devicetrees. Nearly
> all of them use phy-reset-gpios, so that's what I'll use. But,
> when I try to upstream the patch, the maintainer will tell me:
> "no, that is deprecated, use this other method".
> 
> Is there a good solution you can think of which would point
> the unwary developer to the correct phy reset method?

Hi Sven

One option would be to submit a patch or a patchset changing all
existing device tree files to make use of the core method. Anybody
cut/pasting will then automatically use the correct core way of doing
it.

There is also a move towards using YAML to verify the correctness of
DT files. It should be possible to mark the old property as
deprecated, so there will be a build time warning, not a boot time
warning.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ