[From nobody Thu Jun 25 05:54:41 2020 Received: from mail-ot0-x242.google.com ([2607:f8b0:4003:c0f::242]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fS0Jt-0000Bs-Bl for openwrt-devel@lists.openwrt.org; Sun, 10 Jun 2018 13:23:47 +0000 Received: by mail-ot0-x242.google.com with SMTP id r18-v6so6368843otk.1 for <openwrt-devel@lists.openwrt.org>; Sun, 10 Jun 2018 06:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lu8GSGQLpqB8EcYmVuLJMqpxGau25G1/MrryLjUE0Xs=; b=jT5lB3pk4E6JsDW5R9IbEnRAstEfa54ZdcmMNrQM+mx13xm/drhr7pV6v9FT0YfIfR hvZcVJletTrHV/3mBDhM/hsk6iPP+mPBaZZ+FXtqBUXPEljGIET4gmXrNZwWPYizaCDW LxGt0K+pV5HF0mE+1C2mFpEoISW48hp5Sk02t5MeBy6RfPJSKxV6J64gSyMf55hUjjl8 hTmz0W1W5dNlr2xHUY90Ja9GYlzcVfQAQe1/n5cGt6cC7dN7nivI72i1Jut6WU5dkcBI m/64h5SXZc4vFcuIb45H2Ji5N/kVy4MqwviRE8iQUUJ+965UJX1t1xTQHq+/piEI21yU iqMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lu8GSGQLpqB8EcYmVuLJMqpxGau25G1/MrryLjUE0Xs=; b=MijjScGu/6aUfnhXJx0MbG4hpiBOPdN6VTribwVYB+sq5iMhaXSrrxHAL4wsvhCfro PpddSRheAGHYaUhudN9/ALFHCut53cCdUJ+XCOK8xTRINqeEHk9dceuxFFDhLkVlXnTz gauQOosC2y1lvrf4GcLF6shjHTX2dY1eL4x3O0rnvtp5nb9JQUGggWKIQFQGYW0OLEHy QeV1jkjUnk0KSMsn5PHikkSwh0e6tsV+Lz93bmEY2a1jXu9iXYuWCx7inxxZ/94UKdTk 7PV55x5eLccLdHOyQSpmlR8stWOVP6OFvJ0k6LDYxAEu9O3LjCtmhORy6zEV2MEuzVi7 Jt3A== X-Gm-Message-State: APt69E1r4FIhdFmbpfCLHQv9NvamqDKddhiZRtItFCM7UeOarWO27H+M pIUhpw2FMMNne0bzC+mKKQFI/eG/pf3c+27zBp4= X-Google-Smtp-Source: ADUXVKIxKdDRF3eurFnKG1Fw3YVGq2urUvzNr2/RhxqzZN6ninnujuEdGLMIW0ilOdHMVbgzLy8v09/4rHIX/MQoYB8= X-Received: by 2002:a9d:ef7:: with SMTP id 110-v6mr7103236otj.323.1528637013329; Sun, 10 Jun 2018 06:23:33 -0700 (PDT) MIME-Version: 1.0 References: <20180609141342.23948-1-tomek_n@o2.pl> <20180609141342.23948-2-tomek_n@o2.pl> <CAFBinCBJteD_FtmFVdM9bBweB3i39jPu--0LhxxY+xxW6J=LBQ@mail.gmail.com> <0128c190-9779-6249-6555-e4575ac98796@gmail.com> In-Reply-To: <0128c190-9779-6249-6555-e4575ac98796@gmail.com> From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Date: Sun, 10 Jun 2018 15:23:18 +0200 Message-ID: <CAFBinCAsSd8dNhfKO+ggNV0Ko3oXFCGTYp7-gM59M=qwTarkjA@mail.gmail.com> Subject: Re: [OpenWrt-Devel] [PATCH 2/3] mvebu: reduce speed to gen1 for armada 37xx devices pcie To: tmn505@gmail.com Cc: tomek_n@o2.pl, openwrt-devel@lists.openwrt.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180610_062345_420606_FAD45416 X-CRM114-Status: GOOD ( 29.20 ) X-Spam-Score: -0.1 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [2607:f8b0:4003:c0f:0:0:0:242 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (martin.blumenstingl[at]googlemail.com) -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain On Sat, Jun 9, 2018 at 11:09 PM Tomasz Maciej Nowak <tmn505@gmail.com> wrot= e: > > W dniu 09.06.2018 o 19:02, Martin Blumenstingl pisze: > > On Sat, Jun 9, 2018 at 4:15 PM Tomasz Maciej Nowak <tomek_n@o2.pl> wrot= e: > >> > >> Since the beginning there's been an issue with initializing the Athero= s > >> based MiniPCIe wlan cards. Here's an example of kerenel log: > >> > >> advk-pcie d0070000.pcie: Posted PIO Response Status: CA,0xe00 @ 0x3c > >> advk-pcie d0070000.pcie: Posted PIO Response Status: CA,0xe00 @ 0x44 > >> advk-pcie d0070000.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4 > >> ath9k 0000:00:00.0: enabling device (0000 -> 0002) > >> advk-pcie d0070000.pcie: Posted PIO Response Status: CA,0xe00 @ 0x3c > >> advk-pcie d0070000.pcie: Posted PIO Response Status: CA,0xe00 @ 0xc > >> advk-pcie d0070000.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4 > >> advk-pcie d0070000.pcie: Posted PIO Response Status: CA,0xe00 @ 0x40 > >> ath9k 0000:00:00.0: request_irq failed > >> advk-pcie d0070000.pcie: Posted PIO Response Status: CA,0xe00 @ 0x4 > >> ath9k: probe of 0000:00:00.0 failed with error -22 > >> > >> The same happens for ath5k cards, while ath10k card didn't appear at > >> all (not detected). Following the issue on esppressobin.net forum [1] > >> the workaround seems to be limiting the speed of PCIe bridge to 1st > >> generation. This fixed the initialization of ath5k, ath9k and ath10k > >> cards. The change shouldn't affect the performance for wireless cards, > >> it could reduce the performance of storage controller cards but since > >> OpenWrt focuses on wireless connectivity, fixing compatibility with > >> wireless cards should be a priority. > >> For the record, the iwlwifi and mt76 cards were not affected by this > >> issue. > > does this meant that the PCIe link speed depends on the board? > > No, that depends on the SoC board has and PCIe card which negotiates the = speed and capabilities. It shouldn't depend on the board, of course if ther= e are no design faults. Maybe some code in Atheros drivers also affects thi= s or there's bug in aardvark enumerating code. The assessment of this is ou= tside of my skills. I was curious because officially the SoCs from the Armada 3700 series support PCIe 2.0, so it seems strange to force/limit the hardware to PCIe 1.0 > > > > the PCI dt-bindings already specify a "max-link-speed" property, see [0= ] > > there's even a helper function to parse that property: of_pci_get_max_l= ink_speed > > > > this would give you control over the PCIe link speed per board (I am > > assuming that the mvebu target uses devicetree). > > I tried this before submitting the patch, just to be sure retried it afte= r Your mail. Setting this had no effect, the state was as if there was no c= hange. as far as I can see the pci-aardvark driver does not parse the "max-link-speed" devicetree property yet (because it does not use/call of_pci_get_max_link_speed). so to use the "max-link-speed" property one would: - implement support for it in the driver - add the property to the .dts file > > additionally this would allow you to send the patch upstream so > > OpenWrt doesn't have to carry custom patches around forever > > > > what do you think? > > This driver still is in early stage, there are still some issues, until i= t'll be more mature I'm reluctant to send this workaround upstream or sendi= ng bug report. Thomas Petazzoni from Bootlin is working on this driver and = still has some pending changes but that will take few months. Until his cha= nges will hit upstream I'm inclined to keep this. I'm not against adding this patch it just seems to me that all PCI related kernel patches in OpenWrt are backports from upstream patches so why not report your issue upstream, work on a fix with them and backport the result (this will make kernel updates on the mvebu target easier, since it'll allow dropping patches when updating rather then having to figure out why they are still needed, rebasing and testing them again, ...) > There is also upcoming device from CZ.nic, namely Turris MOX, which is ba= sed on the same processor as ESPRESSObin. They already submitted watchdog d= river to LKML and U-Boot tree and minor fixes to U-Boot. Maybe their involv= ement will speed up the changes and we'll see this workaround unnecessary. by sending your patch (even if you think that it's not in shape to be applied upstream - then just state that explicitly) upstream you may save other developers lots of time since you already found a way to make some Atheros PCIe devices work with this controller/driver :) Regards Martin ]