linux-kernel - Re: [PATCH v8 00/26] Ingenic TCU patchset v8

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:   Fri, 25 Jan 2019 14:04:50 -0300
From:   Paul Cercueil <paul@...pouillou.net>
To:     Mathieu Malaterre <malat@...ian.org>
Cc:     Paul Burton <paul.burton@...s.com>,
        James Hogan <jhogan@...nel.org>,
        Ezequiel Garcia <ezequiel@...labora.co.uk>,
        PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, linux-mips@...r.kernel.org,
        linux-clk@...r.kernel.org
Subject: Re: [PATCH v8 00/26] Ingenic TCU patchset v8

Hi,

On Fri, Jan 25, 2019 at 5:21 AM, Mathieu Malaterre <malat@...ian.org> 
wrote:
> Paul,
> 
> On Thu, Jan 24, 2019 at 10:41 PM Paul Cercueil <paul@...pouillou.net 
> <mailto:paul@...pouillou.net>> wrote:
>> 
>>  Hi Mathieu,
>> 
>>  Le jeu. 24 janv. 2019 à 18:26, Mathieu Malaterre <malat@...ian.org 
>> <mailto:malat@...ian.org>> a
>>  écrit :
>>  > Paul,
>>  >
>>  > On Wed, Dec 12, 2018 at 11:09 PM Paul Cercueil 
>> <paul@...pouillou.net <mailto:paul@...pouillou.net>>
>>  > wrote:
>>  >>
>>  >>  Hi,
>>  >>
>>  >>  Here's the version 8 and hopefully final version of my patchset,
>>  >> which
>>  >>  adds support for the Timer/Counter Unit found in JZ47xx SoCs 
>> from
>>  >>  Ingenic.
>>  >
>>  > I can no longer boot my MIPS Creator CI20 with this series (merged
>>  > opendingux/for-upstream-timer-v8).
>>  >
>>  > Using screen+ttyUSB, I can see messages stopping at:
>>  >
>>  > ...
>>  > [  OK  ] Started Cgroup management daemon.
>>  >          Starting Regular background program processing daemon...
>>  > [  OK  ] Started Regular background program processing daemon.
>>  >          Starting System Logging Service...
>>  >          Starting Provide limited super user privileges to 
>> specific
>>  > users...
>>  >          Starting Restore /etc/resolv.conf if the system cras...s
>>  > shut down....
>>  >          Starting WPA supplicant...
>>  >          Starting D-Bus System Message Bus...
>>  > [  OK  ] Started D-Bus System Message Bus.
>>  >
>>  > Nothing really stands out in the error messages. Could you suggest
>>  > things to try out to get into a bootable state ?
>> 
>>  I'm debugging it right now on jz4740, it seems to happen when the
>>  clocksource
>>  from the ingenic-timer driver is used. Is it your case? It should 
>> not
>>  happen
>>  if you have CONFIG_INGENIC_OST set.
> 
> Here is what I see:
> 
> $ grep CONFIG_INGENIC_OST arch/mips/configs/ci20_defconfig
> CONFIG_INGENIC_OST=y
> $ make O=ci20 ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- ci20_defconfig
> $ grep CONFIG_INGENIC_OST ci20/.config
> CONFIG_INGENIC_OST=y
> 
> The setting is coming from your commit:
> 
> 8f66e6b9c98f MIPS: CI20: defconfig: enable OST driver
> 
> In an attempt to solve the symptoms I even played with the clock rates
> with no success:
> 
> &tcu {
> /* 3 MHz for the system timer and clocksource */
> assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER1>;
> assigned-clock-rates = <750000>, <750000>;
> };

This driver didn't see any big change since v6, and we're at v9 now.
I swear it worked fine before, I think even Paul Burton tested it and
reported it working fine. What kernel are you testing on? Could you try
on top of an older kernel, e.g. 4.18?

>>  >>  The big change is that the timer driver has been simplified. The
>>  >> code to
>>  >>  dynamically update the system timer or clocksource to a new 
>> channel
>>  >> has
>>  >>  been removed. Now, the system timer and clocksource are 
>> provided as
>>  >>  children nodes in the devicetree, and the TCU channel to use for
>>  >> these
>>  >>  is deduced from their respective memory resource. The PWM driver
>>  >> will
>>  >>  also deduce from its memory resources whether a given PWM 
>> channel
>>  >> can be
>>  >>  used, or is reserved for the system timers.
>>  >>
>>  >>  Kind regards,
>>  >>  - Paul Cercueil
>>  >>
>>