linux-kernel - Re: [PATCH v8 05/26] clocksource: Add driver for the Ingenic JZ47xx OST

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: <1548362788.3881.0@crapouillou.net>
Date:   Thu, 24 Jan 2019 17:46:28 -0300
From:   Paul Cercueil <paul@...pouillou.net>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Mathieu Malaterre <malat@...ian.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paul.burton@...s.com>,
        James Hogan <jhogan@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Ezequiel Garcia <ezequiel@...labora.co.uk>,
        PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>,
        linux-pwm@...r.kernel.org,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        linux-watchdog@...r.kernel.org, linux-mips@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-clk@...r.kernel.org, od@...c.me,
        Maarten ter Huurne <maarten@...ewalker.org>
Subject: Re: [PATCH v8 05/26] clocksource: Add driver for the Ingenic JZ47xx
 OST



Le jeu. 24 janv. 2019 à 16:28, Stephen Boyd <sboyd@...nel.org> a 
écrit :
> Quoting Guenter Roeck (2019-01-23 10:01:55)
>>  On Wed, Jan 23, 2019 at 02:25:53PM -0300, Paul Cercueil wrote:
>>  > Hi,
>>  >
>>  > Le mer. 23 janv. 2019 Ã  11:31, Guenter Roeck 
>> <linux@...ck-us.net> a Ã©crit :
>>  > >On 1/23/19 4:58 AM, Mathieu Malaterre wrote:
>>  > >>On Wed, Dec 12, 2018 at 11:09 PM Paul Cercueil 
>> <paul@...pouillou.net>
>>  > >>wrote:
>>  > >>>
>>  > >>>From: Maarten ter Huurne <maarten@...ewalker.org>
>>  > >>>
>>  > >>>OST is the OS Timer, a 64-bit timer/counter with buffered 
>> reading.
>>  > >>>
>>  > >>>SoCs before the JZ4770 had (if any) a 32-bit OST; the JZ4770 
>> and
>>  > >>>JZ4780 have a 64-bit OST.
>>  > >>>
>>  > >>>This driver will register both a clocksource and a sched_clock 
>> to the
>>  > >>>system.
>>  > >>>
>>  > >>>Signed-off-by: Maarten ter Huurne <maarten@...ewalker.org>
>>  > >>>Signed-off-by: Paul Cercueil <paul@...pouillou.net>
>>  > >>>---
>>  > >>>
>>  > >>>Notes:
>>  > >>>      v5: New patch
>>  > >>>
>>  > >>>      v6: - Get rid of SoC IDs; pass pointer to 
>> ingenic_ost_soc_info
>>  > >>>as
>>  > >>>            devicetree match data instead.
>>  > >>>          - Use device_get_match_data() instead of the of_* 
>> variant
>>  > >>>          - Handle error of dev_get_regmap() properly
>>  > >>>
>>  > >>>      v7: Fix section mismatch by using
>>  > >>>builtin_platform_driver_probe()
>>  > >>>
>>  > >>>      v8: builtin_platform_driver_probe() does not work 
>> anymore in
>>  > >>>          4.20-rc6? The probe function won't be called. Work 
>> around
>>  > >>>this
>>  > >>>          for now by using late_initcall.
>>  > >>>
>>  > >
>>  > >Did anyone notice this ? Either something is wrong with the 
>> driver, or
>>  > >with the kernel core. Hacking around it seems like the worst 
>> possible
>>  > >"solution".
>>  >
>>  > I can confirm it still happens on 5.0-rc3.
>>  >
>>  > Just to explain what I'm doing:
>>  >
>>  > My ingenic-timer driver probes with builtin_platform_driver_probe 
>> (this
>>  > works),
>>  > and then calls of_platform_populate to probe its children. This 
>> driver,
>>  > ingenic-ost, is one of them, and will fail to probe with
>>  > builtin_platform_driver_probe.
>>  >
>> 
>>  The big question is _why_ it fails to probe.
>> 
> 
> Are you sharing the device tree node between a 'normal' platform 
> device
> driver and something more low level DT that marks the device's backing
> DT node as OF_POPULATED early on? That's my only guess why it's not
> working.

I do, but I clear the OF_POPULATED flag so that it is then probed as a
normal platform device, and it's not on this driver's node but its 
parent.