linux-kernel - Re: [PATCH 30/35] irqchip: add irq-omap-intc.h header

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: <20140729151936.GC17808@saruman.home>
Date:	Tue, 29 Jul 2014 10:19:36 -0500
From:	Felipe Balbi <balbi@...com>
To:	Tony Lindgren <tony@...mide.com>
CC:	Felipe Balbi <balbi@...com>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux ARM Kernel Mailing List 
	<linux-arm-kernel@...ts.infradead.org>, <bcousson@...libre.com>,
	<linux@....linux.org.uk>, <khilman@...prootsystems.com>,
	<tglx@...utronix.de>, <jason@...edaemon.net>,
	<devicetree@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 30/35] irqchip: add irq-omap-intc.h header

On Tue, Jul 29, 2014 at 08:06:55AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@...com> [140729 07:13]:
> > On Tue, Jul 29, 2014 at 05:01:33AM -0700, Tony Lindgren wrote:
> > > * Felipe Balbi <balbi@...com> [140728 14:19]:
> > > > OMAP INTC irqchip driver will be moved under
> > > > drivers/irqchip/ soon but we still have a dependency
> > > > with mach-omap2 when it comes to idle functions.
> > > > 
> > > > In order to make it easy to share those function
> > > > prototypes with OMAP PM code, we introduce this new
> > > > header.
> > > > 
> > > > Signed-off-by: Felipe Balbi <balbi@...com>
> > > > ---
> > > >  arch/arm/mach-omap2/board-3430sdp.c        |  1 +
> > > >  arch/arm/mach-omap2/board-am3517crane.c    |  1 +
> > > >  arch/arm/mach-omap2/board-am3517evm.c      |  1 +
> > > >  arch/arm/mach-omap2/board-cm-t35.c         |  1 +
> > > >  arch/arm/mach-omap2/board-cm-t3517.c       |  1 +
> > > >  arch/arm/mach-omap2/board-devkit8000.c     |  1 +
> > > >  arch/arm/mach-omap2/board-ldp.c            |  1 +
> > > >  arch/arm/mach-omap2/board-omap3beagle.c    |  1 +
> > > >  arch/arm/mach-omap2/board-omap3logic.c     |  1 +
> > > >  arch/arm/mach-omap2/board-omap3pandora.c   |  1 +
> > > >  arch/arm/mach-omap2/board-omap3stalker.c   |  1 +
> > > >  arch/arm/mach-omap2/board-omap3touchbook.c |  1 +
> > > >  arch/arm/mach-omap2/board-overo.c          |  1 +
> > > >  arch/arm/mach-omap2/board-rx51.c           |  1 +
> > > >  arch/arm/mach-omap2/board-ti8168evm.c      |  1 +
> > > >  arch/arm/mach-omap2/common.h               |  9 ---------
> > > >  arch/arm/mach-omap2/cpuidle34xx.c          |  1 +
> > > >  arch/arm/mach-omap2/irq.c                  |  1 +
> > > >  arch/arm/mach-omap2/pm24xx.c               |  1 +
> > > >  arch/arm/mach-omap2/pm34xx.c               |  1 +
> > > >  include/linux/irqchip/irq-omap-intc.h      | 32 ++++++++++++++++++++++++++++++
> > > ...
> > > 
> > > > +void omap2_init_irq(void);
> > > > +void omap3_init_irq(void);
> > > > +void ti81xx_init_irq(void);
> > > 
> > > I think these will all go away with DT based booting?
> > > So it might be worth waiting for that rather than churn
> > > all these files, or..
> > 
> > you just asked me to rebase this series because now we had OMAP3 idle
> > working with DT. And now, you're asking me to hold on to this series
> > because not everything is DT-based yet.
> 
> I just don't like the idea of patching all these board files that
> are going away anyways. If we need to do that, let's just add it

when are they going away ? Are we really gonna delay this series until
those board-files eventually vanish ?

> to common.h that's already included by all the remaining board-*.c
> files. I know we should rather include the files directly, but in
> this case that's just extra churn.
> 
> The real problem is how to properly deal with the save and
> restore calls that idle code needs.

well, for system sleep we have callbacks from irq generic itself. The
real problem is just with runtime PM.

> In any case, it seems we can merge quite a bit of this series
> already and then deal with the problem parts.

sure, it at least some of those patches get merged, then it's less crap
for me to rebase every now and again.

> > This is the third time I rebase the series after a long hiatus and it
> > always comes out to the same result -> "let's wait some more".
> 
> Nope, it's always been "this series causes PM regressions"

you just said that we haven't been in any position to really test this,
so can it be that the status has always been "this series causes PM
regressions". We couldn't test that before, right ?

> and few other minor comments. And we have not been in any
> position to really test that until with v3.16-rc4. And then
> you always run out of time and nobody else does anything :)

sure, I have other stuff to do as well.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)