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: <1484736987.2133.188.camel@linux.intel.com>
Date:   Wed, 18 Jan 2017 12:56:27 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org
Subject: Re: [PATCH v2 1/1] x86/rtc: Allocate interrupt for platform device

On Wed, 2017-01-18 at 11:24 +0100, Thomas Gleixner wrote:
> On Tue, 17 Jan 2017, Andy Shevchenko wrote:
> 
> > On Mon, 2017-01-16 at 22:00 +0100, Thomas Gleixner wrote:
> > 
> > > The early callback does not work, but we have one which is invoked
> > > later
> > > on: x86_init.wallclock_init(). That's invoked after the (IO/APIC)
> > > setup has
> > > been completed. See patch below.
> > 
> > Unfortunately it is till too early. Looks like descriptors are not
> > available yet and we still can't get an allocation:
> > 
> > [    0.000000] intel_mid: Failed to allocate RTC interrupt.
> > Disabling
> > RTC
> > 
> > ...
> > 
> > [    0.000000] NR_IRQS:4352 nr_irqs:512 0
> 
> Indeed. Did not think about that we need the irq subsystem up not only
> the
> primary IOAPIC init done.
> 
> Looking deeper it's actually simple. MID already overloads the
> timer_init()
> setup function. So we can just do it there.

Yes, it does. However I have another solution, just would like to
discuss.

There is a timekeeping_init() call, which is a first user of the RTC.
I have 3 changes:
- introduce arch_pre_timekeeping_init() and move wallclock_init() call
there
- use almost your initial suggestion
- move wallclock_init() to x86_platform and rename to init_wallclock()
to be consistent with the rest of wallclock API (this, though, has item
to discuss, i.e. __init use for callbacks)

This would allow to clearly initialize virtual RTC or legacy one at the
same know point.

What do you think? Should I send a series for review?

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ