Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934591AbcJZRWN (ORCPT ); Wed, 26 Oct 2016 13:22:13 -0400 Received: from us01smtprelay-2.synopsys.com ([198.182.47.9]:37347 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934911AbcJZRV5 (ORCPT ); Wed, 26 Oct 2016 13:21:57 -0400 Subject: Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map To: Marc Zyngier References: <1477313194-2310-1-git-send-email-yuriy.kolerov@synopsys.com> <1477313194-2310-4-git-send-email-yuriy.kolerov@synopsys.com> <39eae1ef-85d1-6dfb-b9fc-a052012c1fbf@synopsys.com> <127dbe3b-c9a9-3718-a711-128505ee363f@arm.com> <861sz39iek.fsf@arm.com> CC: Yuriy Kolerov , , , , Newsgroups: gmane.linux.kernel,gmane.linux.kernel.arc From: Vineet Gupta Message-ID: <486a41ac-1bbf-c0f2-662e-3fea1d1f446b@synopsys.com> Date: Wed, 26 Oct 2016 10:21:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <861sz39iek.fsf@arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.161.43] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1689 Lines: 40 On 10/26/2016 09:36 AM, Marc Zyngier wrote: > On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta wrote: >> On 10/26/2016 07:05 AM, Marc Zyngier wrote: >>> It definitely feels weird to encode the interrupt affinity in the DT >>> (the kernel and possible userspace usually know much better than the >>> firmware). What is the actual reason for storing the affinity there? >> >> The IDU intc supports various interrupt distribution modes (Round >> Robin, send to one cpu only etc) whcih in turn map to affinity >> setting. When doing the DT binding, we decided to add that this to DT >> to get the "seed" value for affinity - which user could optionally >> changed after boot. This seemed like a benign design choice at the >> time. > > Right. But is this initial setting something that the kernel has to > absolutely honor? Not necessarily. > The usual behavior is to let kernel pick something > sensible, and let the user mess with it afterwards. Right ! > Is there any part of the kernel that would otherwise depend on this > affinity being set to a particular mode? If the answer is "none", then I > believe we can safely ignore that part of the binding (and maybe > deprecate it in the documentation). Not really. It was relevant for initial bring up of IDU software and hardware. e.g. checking that uart behind idu works fine in both modes for very first user mode prints, which is before you could make the init script cmds to change the affinity etc. But that bridge has long been crossed. So agree that we will ignore the affinity settings from DT and deprecate the binding. Thx for steering us in the right direction. Much appreciated. -Vineet