linux-kernel - Re: [PATCH v7 00/42] ARM: davinci: convert to common clock framework

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:   Wed, 21 Feb 2018 13:01:44 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     David Lechner <david@...hnology.com>
Cc:     linux-clk@...r.kernel.org, devicetree <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Sekhar Nori <nsekhar@...com>,
        Kevin Hilman <khilman@...nel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Adam Ford <aford173@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 00/42] ARM: davinci: convert to common clock framework

2018-02-20 19:39 GMT+01:00 David Lechner <david@...hnology.com>:
> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-19 21:21 GMT+01:00 David Lechner <david@...hnology.com>:
>>>
>>> This series converts mach-davinci to use the common clock framework.
>>>
>>>
>>
>> Hi David,
>>
>> just some quick results from today's playing with v7.
>>
>> I started out with da850-lcdk with my standard rootfs over NFS. I was
>> not able to boot to console so far. The first problem is that mdio
>> fails to probe:
>>
>> libphy: Fixed MDIO Bus: probed
>> davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000
>> davinci_mdio 1e24000.mdio: no live phy, scanning all
>> davinci_mdio: probe of 1e24000.mdio failed with error -5> After some
>> digging I noticed that the supplied clock rate differs
>> between mainline (114000000Hz) vs common-clock-v7 (18000000). Since
>> we're not setting the rate in mdio, using LPSC_SET_RATE_PARENT would
>> not help like with lcdc.
>
>
> Can you post the output of this command so that I can see how your
> clocks are setup:
>
> cat /sys/kernel/debug/clk/clk_summary
>
>
>>
>> After that, the boot just hangs without ever getting to emac's probe.
>
>
> Using your workaround, can you run:
>
> cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
>
> If you see:
>   1e27000.clock-controller: emac  off-0
>
> then genpd is not working like it is supposed to. You should see something
> like this for device that are working:
>           1e27000.clock-controller: uart2  on
>     /devices/platform/soc@...0000/1d0d000.serial        active
>
>
>>
>> Once I set the emac clock to always enabled (a workaround that was
>> necessary with v6, but could be dropped with my first
>> genpd-in-a-separate-driver attempt), I'm getting a rather strange NULL
>> pointer dereference:
>
>
> I noticed this too when adding the power-domains property to some device
> tree nodes. This is part of the reason why I didn't add it everywhere.
> I wasn't able to figure out the cause of this yet. As a work around
> though, please try removing the power-domains property from the emac
> and mdio nodes and use your previous workaround of having an always
> enabled clock.
>
>

When I use any of the workarounds I just keep getting more problems
(e.g. [1] from blk and pinctrl). I only had a couple hours today to
play with it but it seems to me we have some memory corruption
somewhere. I'll check the initialization order of all the frameworks
involved tomorrow.

Best regards,
Bartosz

[1] https://pastebin.com/75mkkuJL