linux-kernel - Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource

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: <yw1xr3l5k9fo.fsf@unicorn.mansr.com>
Date:	Thu, 08 Oct 2015 10:15:39 +0100
From:	Måns Rullgård <mans@...sr.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource

Mark Rutland <mark.rutland@....com> writes:

>> >> +- clocks: phandle to the source clock
>> >
>> > Is the frequency expected to be exactly the source clock frequency? I
>> > imagine it's possible for there to be a divisor.
>> 
>> There could of course be, though there isn't in the hardware I'm dealing
>> with.  Is specifying it here preferable using a fixed-factor-clock?
>
> I'm not actually sure; I guess it would be ok to do so.
>
> For now we should just explicitly state that the clocksource is assumed
> to tick at the rate of the clock.

OK, I'll come up with a clearer wording.

>> > We can add properties for that later, but we should be explcit as to
>> > what we currently expect the relationship between the clock and the
>> > clocksource to be.
>> >
>> >> +- clocksource-bits: number of valid bits
>> >> +- clocksource-rating: rating of the clocksource
>> >
>> > NAK. This has no meaning w.r.t. the hardware. This should not be in the
>> > DT. If there are criteria that bias this (e.g. frequency, latency), they
>> > should either be described in the DT or determined dynamically.
>> 
>> I had a bad feeling about this.  How would you suggest determining a
>> suitable value from actual hardware parameters?
>
> I don't have a good answer to that given the rating is semi-arbitrary,
> but that's also the reason I don't want to see it in the DT.
>
> Can we not just choose a fixed number in the driver for now? Likely
> something lower than the architected timers (400 currently).

Fine with me.

>> >> +- linux,sched-clock: boolean, register clocksource as sched_clock
>> >
>> > Likewise, this property doesn't belong in the DT for the same reasons as
>> > clocksource-rating.
>> 
>> What would be a proper way to select a sched_clock source?  I realise
>> it's a Linux-specific thing and DT is supposed to be generic, but the
>> information must be provided somehow.
>
> I think that any source above a certain rate and below a certain
> latency, which does not lose state, should be registered (and the best
> gets chosen dynamically).
>
> Come to think of it, what's the expected behaviour of this source w.r.t.
> power management? I expect that the kernel needs to leave the clock
> enabled at all times for this to possibly work.

The platform I'm dealing with has a 32-bit register counting cycles of
the external clock input which never stops.  It also has a few counters
with a configurable clock source, and those might indeed stop so should
probably not be used for this.

-- 
Måns Rullgård
mans@...sr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/