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:   Thu, 22 Feb 2018 14:36:36 +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-21 18:46 GMT+01:00 Bartosz Golaszewski <brgl@...ev.pl>:
> 2018-02-21 18:05 GMT+01:00 David Lechner <david@...hnology.com>:
>> On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote:
>>>
>>> 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
>>>
>>
>> I wonder if we need to delete all of the __init and __initconst attributes
>> now that this has been converted to platform devices.
>>
>
> Duh... Of course we do. IIRC everything in the init section gets
> removed after late_initcall. I'll test that tomorrow.
>
> Bart

It's not that. Not only anyway as it doesn't fix anything, I'm getting
the exact same panics. I tried to play with various settings, like
initializing the platform driver later in the boot sequence etc. but
haven't yet figured out what's going on.

Bart