From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752563AbcFJKKX (ORCPT ); Fri, 10 Jun 2016 06:10:23 -0400 Received: from ni.piap.pl ([195.187.100.4]:35673 "EHLO ni.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750710AbcFJKKV (ORCPT ); Fri, 10 Jun 2016 06:10:21 -0400 From: khalasa@piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=) To: Arnd Bergmann Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow" References: <20160531215802.30590.97398.stgit@bhelgaas-glaptop2.roam.corp.google.com> <11128570.JeBAgI5zQr@wuerfel> <7440319.e8dDgNlZLB@wuerfel> Date: Fri, 10 Jun 2016 12:10:14 +0200 In-Reply-To: <7440319.e8dDgNlZLB@wuerfel> (Arnd Bergmann's message of "Thu, 09 Jun 2016 16:42:03 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 97757 [Jun 10 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: khalasa@piap.pl X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 4174176, 4174207, 4174047 X-KLMS-AntiSpam-Info: LuaCore: 467 467 4123c34640df71f558aee0cc1bf62df53cd3fd7b, Auth:dkim=none X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/06/09 13:58:20 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/06/10 04:57:00 #7518165 X-KLMS-AntiVirus-Status: Clean, skipped Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Arnd Bergmann writes: > Before that, we were always setting both mrrs and mps. As we don't know > who uses PCIE_BUS_PEER2PEER, maybe another option would be to add yet > another pcie_bus_config value for this particular quirk? It would be a safe approach. Or, maybe another non-pcie_bus_config thing, I don't know (so the pcie_bus_config is left for the user). > I started the DT conversion a long time ago (see the DT parsing in > arch/arm/mach-cns3xxx/core.c) but I never had any hardware to test > on, and it was at a time when we didn't even have DT support in all > the subsystems. > > I'd definitely help you get the rest of the DT support in place if > you can test it. This is now the only SMP platform and one of > the last users of GIC and l2x0 that does not use DT, so I'd love > to see that converted just so we can remove the legacy probing from > those drivers. Ok. Is there a DT skeleton file somewhere, so I can try to boot the board (without Laguna extras) in DT mode? At first, I only need CPU + RAM + console serial port. > Converting what we have in mainline should be fairly straightforward, > but there is more code in > target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/laguna.c that requires > more work, in particular we need to come up with a way to handle > the laguna_net_data and laguna_info structures, which have some of > the same data that is normall in DT. I assume adding this to U-Boot should be acceptable (for Gateworks, too). They are already doing this to their i.MX6 line Ventana. > Also, the gpio driver doesn't > have a trivial conversion to DT and requires some work to define > a binding and implement that. GPIO is a bit less important ATM, since the boards can boot without it. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland