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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D5D08ECAAD4 for ; Tue, 30 Aug 2022 09:19:12 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id ABE1C8458E; Tue, 30 Aug 2022 11:19:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="JDNkzW+O"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B6F9D84970; Tue, 30 Aug 2022 11:19:08 +0200 (CEST) Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 1DD5984603 for ; Tue, 30 Aug 2022 11:19:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 96FC7B818C0; Tue, 30 Aug 2022 09:19:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 039FDC433C1; Tue, 30 Aug 2022 09:19:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661851144; bh=37uJAEpu1vIgOHnZ81lZvjLWMzrVFgTh1pk3fw99V88=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JDNkzW+OglM2S2m8aVhVd4VS2W5SLkH5K6VoBsIpSKfwAKKhb2se1Cp2ILl/uBomk WfJadAlXg9qB9OpQYjss5u2Djhpu/j2zNqDfMFTJ9cLRe5HUV2rM5RwcRSApwuXZvR XAEGHy0rSzNTkDitoxY/ajBSAaD/ylgxOBqriTkE7QN7ZZhBkj/tF+upP5PdNCc+wq tWqPwFB8rw9fJN8/+oGXf3vZItxtaBCyXjGseWtCPwQ8h30Y4oNVfxS2WlixoNmlT9 VcKOnWZFbvRKsdUjF4e3frdZYGD2BmWpbY0PTdoaT8tq8lIasgyL/49SkOHuvQlQmY XRQTRW/xqC/NA== Received: by pali.im (Postfix) id DC6DF834; Tue, 30 Aug 2022 11:19:00 +0200 (CEST) Date: Tue, 30 Aug 2022 11:19:00 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: "Maciej W. Rozycki" Cc: Stefan Roese , Bin Meng , Simon Glass , u-boot@lists.denx.de Subject: Re: [PATCH v2] pci: Do not enable PCIe GEN3 link retrain workaround by default Message-ID: <20220830091900.7e4wyqonxonngo5d@pali> References: <20220406150911.23927-1-pali@kernel.org> <20220827123005.10239-1-pali@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean On Tuesday 30 August 2022 10:04:51 Maciej W. Rozycki wrote: > On Sat, 27 Aug 2022, Pali Rohár wrote: > > > Moreover this workaround is enabled for all existing hardware and also all > > future PCIe hardware, which opens a hole that other PCIe vendors may > > introduce same HW issue as on systems where this workaround is required and > > nobody would notice it because U-Boot automatically apply workaround for it. > > Why is it a problem? I think I wrote it. One issue is that it is increasing size of SPL image and we really should not include into SPL things which are not required for all target platforms. Lot of boards have size constrained memory requirements and unnecessary features should not be automatically enabled. > Is the intent to cause hassle to end users and > force them to take action when they have a non-working piece of hardware? Vendors should really test their hardware without any automatic workaround. Otherwise we are going into the hell if some workarounds are automatically enabled and nobody notice broken behavior. And vendors really build software with default options and do not care about it if default options are suitable. There is already direction to make all workaround targeted and enabled only for platforms / hardware which really need it. So enabling some workaround for all platforms which are produced and will be produced in the future is step backward. > I'd say in 99% of cases this will only cause frustration and they won't > bother. They will just conclude that either piece of hardware involved is > broken and will throw it away. Just as I almost did. The seller has > offered me a refund, which seems thought to be a universal solution > nowadays (but I need to do what I meant to and getting money back doesn't > solve it). > > And at least I know what U-boot (or indeed firmware) is and have a > general understanding of how computers work. Most people just want to > plug stuff in and use it for whatever their need is. Expecting them to > take action to get things working is wasting their time (which BTW seems > to have been a growing trend in last ~30 years: putting burden on the end > user to get our problems solved, which saves our time and money at the > expense of end user's). The another issue here is that it was not fully investigated where the issue is. If it is processor specific, PCIe switch specific or endpoint specific, or combination of these options. It was just observed that proposed workaround fix this issue on one specific combination. And you confirmed this in previous post, that you are unsure if it is not specific to downstream ports of the switch. We really should not include such "bloatware" code to be enabled for everything, on every one board. You are the first who reported this issue. Nobody else complained about it, so I really do not see reason why all other users and developers must be forced to have it in their U-Boot binaries. Moreover lot of boards on which is U-Boot running do not have PCIe bus exported on the slot and have PCIe devices integrated and soldered on the board. Why on the earth I have to need this workaround also on these boards (which are moreover sized constrained)? > NB I'm slowly getting fed up with the amount of non-working stuff piling > up around. Every other piece of equipment I try doesn't work for one > reason or another and I need to either chase bugs myself or to spend days > and weeks to persuade someone at least to believe a problem is there to > get that sorted. All in my free time I'd rather spend on something else. > I'd welcome things working automagically for a change so that I could > focus on what I mean to be doing, and therefore I take breaking things > deliberately as a major offence. > > FWIW, > > Maciej What other U-Boot developers think?