linux-kernel - Re: [PATCH net-next 2/3] net: phy: add amlogic g12a mdio mux support

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: <13432d537f671c8065693b7e53348f812e8bbc04.camel@baylibre.com>
Date:   Sat, 16 Mar 2019 18:02:45 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Kevin Hilman <khilman@...libre.com>, netdev@...r.kernel.org,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH net-next 2/3] net: phy: add amlogic g12a mdio mux support

On Sat, 2019-03-16 at 03:54 +0100, Andrew Lunn wrote:
> On Thu, Mar 14, 2019 at 03:01:34PM +0100, Jerome Brunet wrote:
> > > +static int _g12a_enable_internal_mdio(struct g12a_mdio_mux *priv)
> 
> You would generally use the _ prefix when you have a locked and an
> unlocked version. I don't see anything like this here. So please drop
> the _ .
> 

will do

> Nice to see the generic clock framework being used. I just wonder if
> this is the correct place to have this clock code. Can it be made part
> of the SoC clock code?

the PLL is local to this particular device.

In 'Soc clock code' (driver/clk/meson in this case) we usually put clock
controllers. Those controllers feeds the different devices of the SoC but we
tends some more clock elements in the consumer device

Usually, it is just a few mux, dividers and gates (like in
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c) but in this case, we have
a PLL. IMO, it belongs here. Do you see a problem with this ?

Jerome

> 
>     Andrew