From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E77E1EB64DA for ; Wed, 12 Jul 2023 08:26:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232587AbjGLI0N (ORCPT ); Wed, 12 Jul 2023 04:26:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232541AbjGLIZt (ORCPT ); Wed, 12 Jul 2023 04:25:49 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3316E1BFA; Wed, 12 Jul 2023 01:20:54 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-4fb96e2b573so10626243e87.3; Wed, 12 Jul 2023 01:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689150050; x=1691742050; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject:from:to:cc :subject:date:message-id:reply-to; bh=Stm2+briN7xTHjyU1YYMiw0ahBy2NrW0BYxEeVzHaDk=; b=feG9mMNPxVH2E1hZYUaeSzFYUPfTzCgAfJQTdrm/iWAC/FRfKwwsii5R3IGUhDbwgx bc3cgKrNPPquwMrXL5Ixcbanxjo6hnnneTcSurxDT+rVWwhbaO6QXMkTu2Nrckm5BCa7 yR0A6kDOv89asIAau6ARtVReRSfO9ZRJjdvYlcL5gSyR7HSyDCuUO4XY6QLGCrHLUdlj jSpYdIZZSx/3cD8xlHZ0h6eZ8lp2ZTkK1/lwmwTibHeuS8kQYABYp8jU28YcWgZ1NBSz jMMdjB3kSSMfdqWz5P1IF5vjoZjawglCahR2YSyQ4X7MNnhhWgygXMogP8PFDf15F4n3 eHag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689150050; x=1691742050; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Stm2+briN7xTHjyU1YYMiw0ahBy2NrW0BYxEeVzHaDk=; b=SernVOh4abjz3kN6XFbeoZqhF2PYZxtKZDQ3FaaVYmFSb0tWhyFGBuEvVnnwAPzaW8 mt9XiBEjuPFZP4KoIzrTiKrPB0mi3zhXZOChvI4OJ5tTr9Le+Y4xYLXciTkJzM7TH1UX 4o9q3fwII5fwFrYc+B7Z9xfArQwqN4EkiW+DNH0IbfVqfsEeQDuZzZoLKoP5PllTpTfH cQG4ehfs3VaOsqqQuKuBH4f6sV9C8xnHNUg1i1ZffnmAgwMrXQu1GghiHGxjg9PCLt4w Ai9VvaacZvBaA33fCSraLNNIOzQahsGvsaVwBc362IOTzVYnIvRZSEOVVuJtJIL3rtUy njsA== X-Gm-Message-State: ABy/qLaEZKORDFxY2TyqKhTWYB8nzCyEPoird/YmPKE6CZn/bcYvEHaH Yd426dyHBWZsdOryWKWLU5wrfnNvj9s= X-Google-Smtp-Source: APBJJlHz4hYlxCwgr1mnFSAkZqZCx64MZvnbcWfrr2bR7jLPqI0yB4T6F1AhFbmI6sIrFbRLZQFG1Q== X-Received: by 2002:ac2:4e07:0:b0:4f8:5e49:c613 with SMTP id e7-20020ac24e07000000b004f85e49c613mr17263551lfr.43.1689150049426; Wed, 12 Jul 2023 01:20:49 -0700 (PDT) Received: from [192.168.1.103] ([31.173.82.245]) by smtp.gmail.com with ESMTPSA id u16-20020ac25190000000b004fbdf1c85b5sm614017lfi.116.2023.07.12.01.20.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jul 2023 01:20:48 -0700 (PDT) Subject: Re: [PATCH] sh: Avoid using IRQ0 on SH3 and SH4 To: David Laight , 'John Paul Adrian Glaubitz' , Guenter Roeck , Sergey Shtylyov , Geert Uytterhoeven Cc: Yoshinori Sato , Rich Felker , "linux-sh@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <7b2c0d812280afaefee0c70a9aea00a0fcf84e3a.camel@physik.fu-berlin.de> <1178f8d0-be70-c088-ee6a-8b421b290624@roeck-us.net> From: Sergei Shtylyov Message-ID: Date: Wed, 12 Jul 2023 11:20:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/12/23 11:12 AM, David Laight wrote: >> Sent: 09 July 2023 00:13 > .... >> Looking at arch/sh/boards/mach-r2d/irq.c, there is some IRQ translation going >> on and maybe that's the part where we need to correct the offset by 16? > > Would it be less problematic to use (say) 16 for IRQ_0 > leaving IRQ_1+ as 1+ ? I don't think so. > At least that would only cause issues for code that needed > to use IRQ_0. > > (It has to be said that making IRQ 0 invalid seemed wrong > to me. x86 (IBM PC) gets away with it because IRQ 0 is > always assigned to platform specific hardware.) Not only x86, IIRC. Have you seen the commit below? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce753ad1549cbe9ccaea4c06a1f5fa47432c8289 IOW, try arguing with Linus. :-) > David MBR, Sergey