From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753426AbaLDJbx (ORCPT ); Thu, 4 Dec 2014 04:31:53 -0500 Received: from mail-lb0-f174.google.com ([209.85.217.174]:51833 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752056AbaLDJbv convert rfc822-to-8bit (ORCPT ); Thu, 4 Dec 2014 04:31:51 -0500 MIME-Version: 1.0 In-Reply-To: References: <20141203121753.5936.36253.sendpatchset@w520> <20141203121813.5936.17433.sendpatchset@w520> <20141204072153.GE25806@verge.net.au> Date: Thu, 4 Dec 2014 10:31:48 +0100 X-Google-Sender-Auth: Tdvz4ZYTjMWiX5wFkKroj-K_XNI Message-ID: Subject: Re: [PATCH 02/02] ARM: shmobile: marzen-reference: Remove IRLM workaround From: Geert Uytterhoeven To: Magnus Damm Cc: Simon Horman , SH-Linux , linux-kernel , Thomas Gleixner , Jason Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Magnus, On Thu, Dec 4, 2014 at 10:24 AM, Magnus Damm wrote: > On Thu, Dec 4, 2014 at 6:19 PM, Geert Uytterhoeven wrote: >> On Thu, Dec 4, 2014 at 8:33 AM, Magnus Damm wrote: >>>>> --- 0002/arch/arm/boot/dts/r8a7779.dtsi >>>>> +++ work/arch/arm/boot/dts/r8a7779.dtsi 2014-12-03 20:27:49.000000000 +0900 >>>>> @@ -139,7 +139,7 @@ >>>>> interrupt-controller; >>>>> }; >>>>> >>>>> - irqpin0: irqpin@fe780010 { >>>>> + irqpin0: irqpin@fe780000 { >>>>> compatible = "renesas,intc-irqpin-r8a7779", "renesas,intc-irqpin"; >>>>> #interrupt-cells = <2>; >>>>> status = "disabled"; >>>>> @@ -148,7 +148,8 @@ >>>>> <0xfe780010 4>, >>>>> <0xfe780024 4>, >>>>> <0xfe780044 4>, >>>>> - <0xfe780064 4>; >>>>> + <0xfe780064 4>, >>>>> + <0xfe780000 4>; >>>> >>>> Is there any order implied by the above list? >>>> Naïvely I would expect it to be sorted numerically. >>> >>> Yes, the driver assumes the register banks to be passed in a certain >>> order. In the case of r8a7779 we add one more register bank at the end >>> for IRLM setup. Register detail (base address, access size, order and >>> bitfield width) varies with SoC version. So the IRLM register will be >>> at different addresses depending on SoC, but the driver wants it at >>> the end of the list. >> >> As these are all individual registers, and there are that many, I think >> it's worth adding a reg-names property to identify the registers. >> Of course the driver still has to support the old anonymous order >> for backwards compatibility. > > If we should rework things, then I propose going the other way around. > =) Basically only passing a single base address with a certain SoC > specific compat string, and based on that letting the driver > internally figure out which register is at what offset and the access > size and bitfield size. That's gonna mean a complete new compatible value. Seems like we shouldn't have added "renesas,intc-irqpin-r8a7779", as the SoC-type was encoded in the reg properties... > Either way we have a limited number of SoCs and they are all old. So your current patch looks like the best option for now (can you promise future R-Car SoCs won't have an intc-irqpin hardware block ;-)? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds