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 smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CE40CC433EF for ; Sun, 8 May 2022 15:02:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) id 962AFC385B0; Sun, 8 May 2022 15:02:40 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.kernel.org (Postfix) with ESMTPS id 75F00C385A4; Sun, 8 May 2022 15:02:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.kernel.org 75F00C385A4 Authentication-Results: smtp.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.kernel.org; spf=none smtp.mailfrom=arndb.de Received: from mail-yw1-f177.google.com ([209.85.128.177]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MAtoX-1ngrkD0Suf-00BNpM; Sun, 08 May 2022 17:02:36 +0200 Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-2f7d7e3b5bfso121628727b3.5; Sun, 08 May 2022 08:02:35 -0700 (PDT) X-Gm-Message-State: AOAM530dv/COTqiLsp1hX5r7FmXEFhKKFbFqSBdeNI6dhqisT0IpUT3Y GTKsT+xfvAVwjTTRbQ4qCk5tkqm7VZ51V97eizo= X-Google-Smtp-Source: ABdhPJxbTpi++I6rfHDjCikv2HNJk3QYOfNP65hhn6On+1lujYkOPjF33yOfZnKt19tjyf5UPS8htLMILILGJixNd5w= X-Received: by 2002:a81:1697:0:b0:2fa:32f9:78c8 with SMTP id 145-20020a811697000000b002fa32f978c8mr10492606yww.135.1652022154717; Sun, 08 May 2022 08:02:34 -0700 (PDT) MIME-Version: 1.0 References: <20220427162123.110458-1-maukka@ext.kapsi.fi> <1509d16c-d244-19c7-610b-4c8ea8ca1624@ext.kapsi.fi> In-Reply-To: From: Arnd Bergmann Date: Sun, 8 May 2022 17:02:17 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree To: Mauri Sandberg List-Id: Cc: Arnd Bergmann , SoC Team , Linux ARM , DTML , Olof Johansson , Rob Herring , Krzysztof Kozlowski , Andrew Lunn , Sebastian Hesselbarth , Thomas Petazzoni , =?UTF-8?Q?Pali_Roh=C3=A1r?= Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:lpBD683nspw/B9Ofa6NSkY2xuVC9dyTSuGGBVTRLdgBbb0iCKgT ZW2y5bUN4hoqP6iDyxzwEAAi8YHRpecp1HVZ5g/J/5Sko0zT62FptX8bM5d64K7cPDpDuNb u7qSBCQoQPt+dsEa1eOBxSssA5b7+U1Gt5NZIiH4abWkoHLhZxmak7uTH/Li+L7X8upvUUb QO98uMsgFFmLbMU0uht5Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:8P4Vq8d+Yrk=:YenCC2t7Ah61MdcTi2fVwG oZuIBgad5wlklZ1pi86y8ONnB+wrujbPjZbZOZCxjO56SYMSqC33fOiuXXnht0GZwvKTSsQ1a kngPiI8uxSlGo8IkKWk8DQJ//zemlxhU/S9knRGUbe99leHbu4J9Z5nuxVirMrmlphTDPs+7G uRf9bBA/kfXdxy3Tof1+8TxDLv0+i4XZwh1M2Y9iTTh7gQ2Sd6ctX6soJpTmmu29W7hKLcnrK dzzZiW0s6jwhKXR7YLZcD3R6Kpe42S42Ks+NMsD76Ks1ahExpN5egO+01tlthHsww2+YZy7gS 7dZ/gq/hivoo06V/Pm0F+dbSvQffFe6IufBwtVzOYCDlmp0jS5ytdappU5djG1asqyWWpcC+P 81f3hiDRCm8Vct0fXRu1NpQ4Tgig4otEgjZ2RHjmpRQV27vY9uhEaugu/ThkgCawJzUh24qCA Klz1HLVPNv7gZeIrKId+n5JqjGKB9zVY2iflNEkcNcWrnNoFrdKcQnCSNBiqsbEAQGUj8GoL0 Co5dtDE8Sjf7727fXpcY5mO/S8jXLMsfQijm2OZAdsaaR9Y2g5U73vWWcP0hw+RNwn3CupkHi VA6ZOqaqkbAy9k5XgF1nxL0ctOjZokJmMFCGPVNv9vsS7kJnzgv0fgJcme7QRysvXfIfg8GuQ u6PtZMdyqdGp4CrW9SLrZZFYIr8czdqivv2QujbaWFeJLr4sRv+a8bUGKajj0quk7/zo= On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg wrote: > On 28.4.2022 23.56, Arnd Bergmann wrote: > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg wrote: > >> On 27.4.2022 21.10, Arnd Bergmann wrote: > >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg wrote: > >>>> - sata_mv fails to initialise with -22 (-EINVAL) > >>> > >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL > >>> from there > >>> > > With debugging the reason for -EINVAL remains a bit mystery. > - sata_mv calls ata_host_activate() [1] > - later on, in request_threaded_irq(), there are sanity checks [2] > - that fail with irq_settings_can_request() returning 0 [3] > > I cannot really put my finger on why the irq cannot be requested in DT > approach. Are you sure the marvell,orion-intc driver is successfully probed at this point? If not, the interrupt won't be there. I see that the "sata_mv" driver can be used either as a platform driver for the orion5x on-chip controller, or as a PCI driver for an add-on chip connected to the external bus. It sounds like your system has both. Do you know which one fails? The PCI driver cannot work unless the PCI host works correctly, and that in turn requires a correct devicetree description for it. > >> Is there a way to describe the PCIe bus in the > >> device tree? The initalisation of that bus is done for rev A1 only. > > > > I'm not too familiar with the platform, but my interpretation is that the > > DT support here is incomplete: > > > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c > > is not hooked up in orion5x.dtsi, and the traditional pci code does > > not work with DT. > > Can the existing pci code still be used to init the PCI bus and describe > the rest in the DT or is it a futile attempt? > > > I see that orion5x has two separate blocks -- a PCIe host that is > > similar to the kirkwood one, and a legacy PCI host that needs > > a completely separate driver. > > > > Which of the two do you actually need here? > > > > I really cannot say which one is it. How can I tell? The functions given > in struct hw_pci find their way to drivers/pci/probe.c eventually and > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or > kirkwood explicitly at least. > > Here's the output from lspci if the ids reveal anything. > > # lspci -v -k > 00:00.0 Class 0580: 11ab:5181 > 01:00.0 Class 0580: 11ab:5181 > 00:01.0 Class 0100: 11ab:7042 sata_mv The first two seem to be the host bridges, but unfortunately they seem both have the same device ID, despite being very different devices. The first one (00:00.0) should be the PCIe driver, the second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 device is a PCIe device, and it's on the bus (00) of the first host bridge. I think this should work with drivers/pci/controller/pci-mvebu.c if you add the bits for probing. Thomas Petazzoni originally wrote the new driver, and I think he was planning at one point to use it for orion5x. I don't know if there were any major problems preventing this at the time, or if it just needs to get hooked up in the dtsi file. Arnd 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0802AC433EF for ; Sun, 8 May 2022 15:03:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=I7ko10oQwDdJoHTPNd/v8qR6cZOQBUa6oykfd8Zr/zg=; b=ShytQkoqcDhHQY WsfbyoMnUfk7bBd4ym+FD4fRhSvVnBhwmbX3n3fTFBkvbTEHwbs+RQ2foqVd/gRD7o9RalrFR8ZFe VamOg0jA5f/r2IlpRjk0JVfeVsnuPpQCGHwpMDZMAojKgnjEwL6PX5EHT3lFgcivHOn+FZEGvZBpc 0VQLcixqo2uvTYOmSA5tMUc8IZt4Vidqpe3vLuz0VuvtBm4QspEcmdEjXV15kXDZ73dNN/JIXTs8V 6k9LTI91RUwBtn1N5Ov/eOqATo9HaeNxmMA9XMHJGk2TbaBSpVAmVJagEDcQARjxtwkaXL7fIGdcO ejsWtLc+ld263g9Fm7lQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nniQr-00ARG8-0O; Sun, 08 May 2022 15:02:49 +0000 Received: from mout.kundenserver.de ([212.227.17.13]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nniQn-00ARAf-3V for linux-arm-kernel@lists.infradead.org; Sun, 08 May 2022 15:02:46 +0000 Received: from mail-yw1-f174.google.com ([209.85.128.174]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MnIxu-1oCum80AIW-00jGoU for ; Sun, 08 May 2022 17:02:36 +0200 Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-2f7d621d1caso121545397b3.11 for ; Sun, 08 May 2022 08:02:35 -0700 (PDT) X-Gm-Message-State: AOAM531m733ScnZ2OJVijxpCU6IzBpUM+r6ziHxt39SOwmB6qcSkD7nI 74XAfoClbyOJ2a/QHOWMB32tOM1kQYWg1WDE8ek= X-Google-Smtp-Source: ABdhPJxbTpi++I6rfHDjCikv2HNJk3QYOfNP65hhn6On+1lujYkOPjF33yOfZnKt19tjyf5UPS8htLMILILGJixNd5w= X-Received: by 2002:a81:1697:0:b0:2fa:32f9:78c8 with SMTP id 145-20020a811697000000b002fa32f978c8mr10492606yww.135.1652022154717; Sun, 08 May 2022 08:02:34 -0700 (PDT) MIME-Version: 1.0 References: <20220427162123.110458-1-maukka@ext.kapsi.fi> <1509d16c-d244-19c7-610b-4c8ea8ca1624@ext.kapsi.fi> In-Reply-To: From: Arnd Bergmann Date: Sun, 8 May 2022 17:02:17 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree To: Mauri Sandberg Cc: Arnd Bergmann , SoC Team , Linux ARM , DTML , Olof Johansson , Rob Herring , Krzysztof Kozlowski , Andrew Lunn , Sebastian Hesselbarth , Thomas Petazzoni , =?UTF-8?Q?Pali_Roh=C3=A1r?= X-Provags-ID: V03:K1:ngp8DeJEKH7lOiGO5Nhk05UAdfzlZlrGGVOVm5lIAWpJOHuCLnf KmGbAis6jjm4wivwBvEfdsUEa3XGV2MrDmZ4UImcYu2zk1RePQmUtNex3Np3iG4328l5AOR i3hKOZ11swbC0hN0exOG6LzE93+Z7z6iwONTz8aHRGcxqoIqtd/bUhg2KSH+Y/Y/3fl0y78 J6vBKGStcKEXqGKa90mzg== X-UI-Out-Filterresults: notjunk:1;V03:K0:6Lwu3BKaW40=:nhYWA4scUgrk0Qhuvxv4vO w3wDF/Pl01coOEYanrZdKQHzlmSXbuGZl+D/+rwi0a/GTBlzhNKu42TjSNkchKSj5a7403gL5 YEdwdo/jqk6o9ZZBNlzzflRPyLp9v34+MTfPv6memRtNIuXtgISF1i9b4PUYOYoKrQcqBoOwj wvsCDO4CMRNYHpfHAox6lrU5hLjBdqF+fJZasdaWnJrxdhendAokALoYWjGnsEUkXwxpB5pYy fDwMvNhsXCSApcUd4D98WHg3XSPn937xZq6m3sXbtpT3Dt6m6wublW7XZL9QKEvzQPx1FwWRP LVgEWMUs2en6oxlCkd/8SJpGEEf22Gy6eF679uZ6LUeeooG4ELKI4aj6wAMgogjiM1PBl9K/N peq94DI4VfsoSVIf0pxiPC3xp6GGbfezAMV4KFfkcgJBhnwB5Q3FKfAEuRy0lH6qcUiUzuAgd qHIQ2jxVmtjeEfZgvDY+wvttnOTAwmdSNrH0Mikb8MnG/yN2FxZLz4rjAHDAuIy3c5fVxjJJo RpbFsCGrwPFC1t9k01pdaPe5Xxi8QL1rDANnTdrqmyKvD9DoLjx/tEBDWmlBfyx8klcKGPsSV Z/I8s4Py6QIEx5DCVlpYYoEWww4HsEyIjLL6GlNwAVRvabZ7aqKM0CAz4mE0xzJHmbnfNbuy8 WiBleYFMa5j+2vDod7w8598YYT3Ci9x1rLUfDExAUrsKHAzofGHtoTzxbYDwCG2Gc2jCRV+Gb Bs4KEYdYyON7kGOMPNxHjnkqneL/7nBXxW7ZqV3A5MNuYN03cS8MXJNS6yudE51fNNFGDQbvh Uz2MqnH2GWzw38QX2IoK+iG+WaeUzK9M08UGHiz/nY03WcUYFg= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220508_080245_447149_48BA13D2 X-CRM114-Status: GOOD ( 38.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg wrote: > On 28.4.2022 23.56, Arnd Bergmann wrote: > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg wrote: > >> On 27.4.2022 21.10, Arnd Bergmann wrote: > >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg wrote: > >>>> - sata_mv fails to initialise with -22 (-EINVAL) > >>> > >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL > >>> from there > >>> > > With debugging the reason for -EINVAL remains a bit mystery. > - sata_mv calls ata_host_activate() [1] > - later on, in request_threaded_irq(), there are sanity checks [2] > - that fail with irq_settings_can_request() returning 0 [3] > > I cannot really put my finger on why the irq cannot be requested in DT > approach. Are you sure the marvell,orion-intc driver is successfully probed at this point? If not, the interrupt won't be there. I see that the "sata_mv" driver can be used either as a platform driver for the orion5x on-chip controller, or as a PCI driver for an add-on chip connected to the external bus. It sounds like your system has both. Do you know which one fails? The PCI driver cannot work unless the PCI host works correctly, and that in turn requires a correct devicetree description for it. > >> Is there a way to describe the PCIe bus in the > >> device tree? The initalisation of that bus is done for rev A1 only. > > > > I'm not too familiar with the platform, but my interpretation is that the > > DT support here is incomplete: > > > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c > > is not hooked up in orion5x.dtsi, and the traditional pci code does > > not work with DT. > > Can the existing pci code still be used to init the PCI bus and describe > the rest in the DT or is it a futile attempt? > > > I see that orion5x has two separate blocks -- a PCIe host that is > > similar to the kirkwood one, and a legacy PCI host that needs > > a completely separate driver. > > > > Which of the two do you actually need here? > > > > I really cannot say which one is it. How can I tell? The functions given > in struct hw_pci find their way to drivers/pci/probe.c eventually and > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or > kirkwood explicitly at least. > > Here's the output from lspci if the ids reveal anything. > > # lspci -v -k > 00:00.0 Class 0580: 11ab:5181 > 01:00.0 Class 0580: 11ab:5181 > 00:01.0 Class 0100: 11ab:7042 sata_mv The first two seem to be the host bridges, but unfortunately they seem both have the same device ID, despite being very different devices. The first one (00:00.0) should be the PCIe driver, the second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 device is a PCIe device, and it's on the bus (00) of the first host bridge. I think this should work with drivers/pci/controller/pci-mvebu.c if you add the bits for probing. Thomas Petazzoni originally wrote the new driver, and I think he was planning at one point to use it for orion5x. I don't know if there were any major problems preventing this at the time, or if it just needs to get hooked up in the dtsi file. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel