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:   Sat, 23 Dec 2017 23:41:01 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     netdev@...r.kernel.org, ingrassia@...genesys.com,
        linus.luessing@...3.blue, khilman@...libre.com,
        linux-amlogic@...ts.infradead.org,
        Neil Armstrong <narmstrong@...libre.com>,
        peppe.cavallaro@...com, alexandre.torgue@...com
Subject: Re: [RFT net-next 2/2] net: stmmac: dwmac-meson8b: don't try to
 change m250_div parent's rate

On Sat, 2017-12-23 at 22:49 +0100, Martin Blumenstingl wrote:
> while calculating this with a target frequency of 500MHz manually
> again I saw that there's a remainder of 10Mhz after the initial
> division.
> remainder * SDM_DEN = 163840000000 - this value overflows 32-bit,
> things will go downhill from here... :)
> long story short: here's a patch for that issue: [0]

Thanks for the fix !

> 
> the results with "CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT" on the mux:

Actually, I don't think you need the CLK_SET_RATE_NO_REPARENT

>     fixed_pll                             3            3  2550000000
>        0 0
>       mpll2                              1            1   124999851
>       0 0
>          c9410000.ethernet#m250_sel           1            1
> 124999851          0 0
>             c9410000.ethernet#m250_div           1            1
> 124999851          0 0
>                c9410000.ethernet#m25_div           1            1
> 24999971          0 0
> 
> this is even closer to 25MHz than the values in the vendor driver
> (120Hz vs 29Hz)
> I'll re-spin this series, then Emiliano "just" has to confirm that
> it's also working for him (despite the dividers in the dwmac-meson8b
> driver are set up different compared to the vendor driver)

if the rate of the parent clock of mux may change, I think following part should
be changed as well

	case PHY_INTERFACE_MODE_RMII:
		/* Use the rate of the mux clock for the internal RMII PHY */
		clk_rate = clk_get_rate(dwmac->m250_mux_clk);

I think it is a bit weak anyway, as it depends on the initial settings. Do you
remember why you wrote this way ?

> 
> > > - according to the datasheet the allowed range of the mpll2 clock is
> > > 250..637MHz - 127488329Hz is what we get from the common clock
> > > framework
> > 
> > Yes, I've seen that but we are able compute out of that range and, so far, the
> > actual rate of clock seems coherent with the calculation. At least, when I
> > tested with the audio, it was the case.
> 
> I'm curious: ...on a GX SoCs probably?

Indeed, you got me !

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ