[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120825171705.GC3363@breakpoint.cc>
Date: Sat, 25 Aug 2012 19:17:05 +0200
From: Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
To: Joerg Roedel <joerg.roedel@....com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, joro@...tes.org,
Suresh Siddha <suresh.b.siddha@...el.com>,
Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH 03/19] x86, io_apic: Introduce x86_io_apic_ops.disable()
On Fri, Aug 24, 2012 at 02:22:26PM +0200, Joerg Roedel wrote:
> Well, yeah, the confusing thing with this patch is, that it does not only
> introduce the x86_io_apic_ops.disable call-back but also adds the
> infrastructure to change this op (and others). So the infrastructure
> change should probably be in a seperate patch. But on the other side the
> infrastructure change is small and the patch-set is already really
> large.
> Is it worth it to split that out?
I don't insist to redo the patch because of this. Please redo the patch
description to better describe what you do. You pull the "irq remap" code out
and stuff it in another function.
> > I don't want sound to picky here but the term 'modify' is bad I think. Would
> > 'overwrite' fit better here? Is 'modify' used someplace else in x86 so you
> > follow a common pattern here? Maybe it is just me.
>
> Probably it's just me, but overwrite sounds like 'replace' (== overwrite
> all ops with own values). But the code changes only a few of the ops
> which need different behavior for interrupt remapping. I think 'modify'
> describes that better, no?
Leave it then :)
>
>
> Joerg
Sebastian
--
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/
Powered by blists - more mailing lists