From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755133Ab3CHULH (ORCPT ); Fri, 8 Mar 2013 15:11:07 -0500 Received: from www.linutronix.de ([62.245.132.108]:56441 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751136Ab3CHULE (ORCPT ); Fri, 8 Mar 2013 15:11:04 -0500 Date: Fri, 8 Mar 2013 21:10:49 +0100 (CET) From: Thomas Gleixner To: Yinghai Lu cc: Ingo Molnar , "H. Peter Anvin" , Bjorn Helgaas , "Rafael J. Wysocki" , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk , Sebastian Andrzej Siewior , Joerg Roedel Subject: Re: [PATCH v2 02/26] x86, irq: Modify irq chip once for irq remapping In-Reply-To: Message-ID: References: <1360351703-20571-1-git-send-email-yinghai@kernel.org> <1360351703-20571-3-git-send-email-yinghai@kernel.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 8 Mar 2013, Thomas Gleixner wrote: > On Fri, 8 Feb 2013, Yinghai Lu wrote: > > > Now after irq remapping is enabled, irq_chip fields are modified during > > every irq setup. > > > > Only need to change them one during we enable irq mapping. > > Can you please start to write sensible changelogs? I'm really sick of > your sloppyness. > > > Also change irq_remap_modify_chip_defaults() to __init. > > Why can you do that ? > > > We don't need to use #ifdef in irq_remap_modify_chips(), as > > IRQ_REMAP only support x86_64 AND X86_IO_APIC AND PCI_MSI, > > also HPET_TIMER is set when x86_64 is set. > > You should not describe what the patch is doing, you are again missing > to describe why the patch is doing this. And just for clarification. If you are not going to provide proper changelogs for _all_ patches of the series, this stuff is going directly towards /dev/null. I'm not wasting my time to review any of that otherwise. Thanks, tglx