Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754284AbbHaTlG (ORCPT ); Mon, 31 Aug 2015 15:41:06 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:47558 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752973AbbHaTlD (ORCPT ); Mon, 31 Aug 2015 15:41:03 -0400 Message-ID: <55E4ADCA.2010008@roeck-us.net> Date: Mon, 31 Aug 2015 12:40:58 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Marc Zyngier CC: Stephen Rothwell , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, "pi-cheng.chen" , Alexei Starovoitov , Mark Brown , Markus Pargmann Subject: Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures) References: <20150831195420.371e8849@canb.auug.org.au> <20150831141736.GA19616@roeck-us.net> <20150831163103.2e13b301@arm.com> <55E476FB.2040208@roeck-us.net> <20150831171807.27d78ff0@arm.com> <55E4838B.5000500@roeck-us.net> <20150831180922.4392875e@arm.com> <20150831192657.557e45cc@why.wild-wind.fr.eu.org> <55E4A38A.6070306@roeck-us.net> <20150831201324.6419ee0d@why.wild-wind.fr.eu.org> In-Reply-To: <20150831201324.6419ee0d@why.wild-wind.fr.eu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3647 Lines: 94 On 08/31/2015 12:13 PM, Marc Zyngier wrote: > On Mon, 31 Aug 2015 11:57:14 -0700 > Guenter Roeck wrote: > >> Hi Marc, >> >> On 08/31/2015 11:26 AM, Marc Zyngier wrote: >> [ ... ] >>> >>> Actually, the kernel dies because of this: >>> >>> commit adaac459759db4a1fd35baddbe47bac700095496 >>> Author: Markus Pargmann >>> Date: Sun Aug 30 09:33:53 2015 +0200 >>> >>> regmap: Introduce max_raw_read/write for regmap_bulk_read/write >>> >>> There are some buses which have a limit on the maximum number of >>> bytes that can be send/received. An example for this is >>> I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of >>> more than 32 bytes. The regmap_bulk operations should still be able >>> to utilize the full 32 bytes in this case. >>> >>> Signed-off-by: Markus Pargmann >>> Signed-off-by: Mark Brown >>> >>> which never considers bus to be NULL in __regmap_init. With the >>> following patch applied, I can boot to a prompt: >>> >>> From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001 >>> From: Marc Zyngier >>> Date: Mon, 31 Aug 2015 19:16:16 +0100 >>> Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL >>> >>> Commit adaac459759d ("regmap: Introduce max_raw_read/write >>> for regmap_bulk_read/write") added new fields to regmap_bus >>> and started using them in __regmap_init, but failed to >>> consider the case where bus would be NULL, like in the >>> vexpress-syscgf case. The box (actually its qemu version) >>> ends up dying painfully. >>> >>> Fix it by testing bus before doing anything else. >>> >>> Signed-off-by: Marc Zyngier >> >> Yes, that fixes the vexpress failures. >> >> Tested-by: Guenter Roeck >> >> However, I still need to revert your patches to get my realview-pb-a8 >> and realview-eb tests to work again. >> >> I am a bit concerned about the use of of_address_to_resource(), >> which can return an error, leaving cpu_res undefined. Also, if >> both CONFIG_OF and CONFIG_ACPI are not configured, supports_deactivate >> is set to true by default. This is the configuration used in my >> failing tests. >> >> With that in mind, I ran a simple test. >> >> -static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE; >> +static struct static_key supports_deactivate = STATIC_KEY_INIT_FALSE; >> >> Bingo, problem solved. Can you try to find a clean solution ? > > Yeah, I just came to the same conclusion, and to the following patch: > > From 059bc80a4fc433dda99d75a712f30a77ce4964bc Mon Sep 17 00:00:00 2001 > From: Marc Zyngier > Date: Mon, 31 Aug 2015 20:00:35 +0100 > Subject: [PATCH] irqchip/gic: Fix EOImode settiing non-DT/ACPI systems > > Non-DT/ACPI systems call directly into the GIC driver at init time. > Since 0b996fd35957 ("irqchip/GIC: Convert to EOImode == 1"), this > breaks old non firmware-driven platforms, as the driver only > works out the capability of the platform on the DT/ACPI paths. > > Fix this thinko by forcing EOImode==0 on non-DT platforms, > which are not capable of supporting a hypervisor anyway. > > Signed-off-by: Marc Zyngier Yep, that fixes the problem. Tested-by: Guenter Roeck Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/