From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755768AbbLGLTe (ORCPT ); Mon, 7 Dec 2015 06:19:34 -0500 Received: from mail-db3on0058.outbound.protection.outlook.com ([157.55.234.58]:8623 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754931AbbLGLTc convert rfc822-to-8bit (ORCPT ); Mon, 7 Dec 2015 06:19:32 -0500 From: Noam Camus To: Marc Zyngier , "linux-snps-arc@lists.infradead.org" CC: "linux-kernel@vger.kernel.org" , "Chris Metcalf" , Thomas Gleixner , "Jason Cooper" Subject: RE: [PATCH v3 04/18] irqchip: add nps Internal and external irqchips Thread-Topic: [PATCH v3 04/18] irqchip: add nps Internal and external irqchips Thread-Index: AQHRLDj4dTCLMG5tRUC3s/7br+9FDp62ICYAgAGqn9CAAc8FgIAFzRfA Date: Mon, 7 Dec 2015 11:19:28 +0000 Message-ID: References: <1448974985-11487-1-git-send-email-noamc@ezchip.com> <1448974985-11487-5-git-send-email-noamc@ezchip.com> <565DA0B6.5080903@arm.com> <56608AFF.80302@arm.com> In-Reply-To: <56608AFF.80302@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=noamc@ezchip.com; x-originating-ip: [212.179.42.66] x-microsoft-exchange-diagnostics: 1;DB4PR02MB125;5:0WnZtUVEWmKSz/whJ+3saa6faErUGn+CuOZYerAC4GHdbJhbM+j/rqfOVB9D7d4YvZ9fb7Fjax5hVbs1ju3G7jfN418jNkZDGJktBI8SEJZO6AslGdnu5hsUeMqKptp0HHepnPggDED5SDUfkZS6Ig==;24:a42f4y5em2BN1MamiKrrAI6IONUOXkwtp2thhUxWBRGjHycEHQ34NdPWf8O+y2nzmWnn2gt+zheWBT2zXTQP6f8YpRWyA4ZS020xGgYB88M= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR02MB125; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046);SRVR:DB4PR02MB125;BCL:0;PCL:0;RULEID:;SRVR:DB4PR02MB125; x-forefront-prvs: 078310077C x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(377454003)(189002)(199003)(102836003)(87936001)(74316001)(106356001)(122556002)(105586002)(106116001)(40100003)(5004730100002)(86362001)(93886004)(586003)(10400500002)(1220700001)(2900100001)(6116002)(1096002)(2950100001)(77096005)(92566002)(2501003)(5001960100002)(189998001)(97736004)(5001770100001)(33656002)(81156007)(5008740100001)(54356999)(76176999)(3846002)(50986999)(101416001)(5002640100001)(19580405001)(76576001)(5003600100002)(19580395003)(66066001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB4PR02MB125;H:DB5PR02MB1141.eurprd02.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2015 11:19:28.5835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fc16e0a-3cd3-4092-8b2f-0a42cff122c3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR02MB125 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marc Zyngier [mailto:marc.zyngier@arm.com] Sent: Thursday, December 03, 2015 8:34 PM >>> Silly question: why cannot you just write the actual instruction >>> instead of shoving the instruction like this? Also, .inst would be >>> more appropriate... >> [Noam Camus] Since this is instruction that yet is not part of >> up-streamed binutils of ARC. Now ARC maintainer can build our kernel >> with generic ARC toolchain. >OK. If you decide to carry on using this, I'd still recommend using .inst instead of .word, so that you can get a proper disassembly. Seem to me that ".inst" is ARM Machine directive. >Also, can you always tell the per-cpu property of your interrupt based on its number? If you can, then it is fine. Yes I can, and I am using this knowledge. >Your alternative is to use irq_domain_add_linear, for example, and to make sure that you always refer to the hw number when manipulating the HW. You will quickly notice that the Linux IRQ number has nothing to do with the HW one, and you'll be able to quickly iron out the bugs. Indeed when I moved from legacy to linear map I had to call irq_create_mapping() for my percpu IRQs and that's it. Thanks -Noam From mboxrd@z Thu Jan 1 00:00:00 1970 From: noamc@ezchip.com (Noam Camus) Date: Mon, 7 Dec 2015 11:19:28 +0000 Subject: [PATCH v3 04/18] irqchip: add nps Internal and external irqchips In-Reply-To: <56608AFF.80302@arm.com> References: <1448974985-11487-1-git-send-email-noamc@ezchip.com> <1448974985-11487-5-git-send-email-noamc@ezchip.com> <565DA0B6.5080903@arm.com> <56608AFF.80302@arm.com> List-ID: Message-ID: To: linux-snps-arc@lists.infradead.org From: Marc Zyngier [mailto:marc.zyngier@arm.com] Sent: Thursday, December 03, 2015 8:34 PM >>> Silly question: why cannot you just write the actual instruction >>> instead of shoving the instruction like this? Also, .inst would be >>> more appropriate... >> [Noam Camus] Since this is instruction that yet is not part of >> up-streamed binutils of ARC. Now ARC maintainer can build our kernel >> with generic ARC toolchain. >OK. If you decide to carry on using this, I'd still recommend using .inst instead of .word, so that you can get a proper disassembly. Seem to me that ".inst" is ARM Machine directive. >Also, can you always tell the per-cpu property of your interrupt based on its number? If you can, then it is fine. Yes I can, and I am using this knowledge. >Your alternative is to use irq_domain_add_linear, for example, and to make sure that you always refer to the hw number when manipulating the HW. You will quickly notice that the Linux IRQ number has nothing to do with the HW one, and you'll be able to quickly iron out the bugs. Indeed when I moved from legacy to linear map I had to call irq_create_mapping() for my percpu IRQs and that's it. Thanks -Noam