u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Stefan Roese <sr@denx.de>
Cc: "Pali Rohár" <pali@kernel.org>, "Bin Meng" <bmeng.cn@gmail.com>,
	"Simon Glass" <sjg@chromium.org>,
	u-boot@lists.denx.de
Subject: Re: [PATCH v2] pci: Do not enable PCIe GEN3 link retrain workaround by default
Date: Sat, 17 Sep 2022 14:02:51 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2209171342020.53071@angie.orcam.me.uk> (raw)
In-Reply-To: <7410275b-8057-e2ae-6b78-b867fcb9547d@denx.de>

On Tue, 30 Aug 2022, Stefan Roese wrote:

> > 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.
> 
> I have to agree with Pali here. We need to be careful with size increase
> in the SPL images, as some of the build targets are very limited here.
> So making this workaround configurable is definitely a good idea.

 I object to having just a single workaround configurable as I expect it 
to be beyond the capability of people on average to get right.  You simply 
start getting lost at one point, just as I am with all the random options 
the Linux kernel has nowadays.  And the dozens added with every release.

 I agree on the SPL side and on a global option.  I think it only makes 
sense to have individual workarounds selectable for onboard devices with 
hardware that has no external PCI/e connectivity.  Those should not be 
exposed to the user and instead implicitly selected by the scriptery based 
on the base machine chosen.

> The question remains, at least for me, if the Kconfig option should be
> enable per default or not. For SPL my suggestions is to disable is per
> default because of the size remarks above. For U-Boot proper I'm not so
> sure. Please see below...

 FWIW Linux has a global PCI_QUIRKS option available in the expert mode 
only that lets one disable all workarounds:

config PCI_QUIRKS
	default y
	bool "Enable PCI quirk workarounds" if EXPERT
	help
	  This enables workarounds for various PCI chipset bugs/quirks.
	  Disable this only if your target machine is unaffected by PCI
	  quirks.

for U-Boot I could envisage something like:

config PCI_QUIRKS
	bool "Enable PCI quirk workarounds" if EXPERT
	default y if !SPL
	[...]

Leaving just a single workaround out, especially for option card devices 
is asking for people getting it wrong.

 If there are individual workarounds required by hardware with no external 
PCI/e connectivity, then we could have say:

config PCI_QUIRKS
	bool "Enable PCI quirk workarounds" if EXPERT
	default y if !SPL
	select SPECIFIC_QUIRK_FOR_BADLY_BROKEN_BOARD

config BADLY_BROKEN_BOARD
	bool "Enable support for Badly Broken Board"
	select SPECIFIC_QUIRK_FOR_BADLY_BROKEN_BOARD

config SPECIFIC_QUIRK_FOR_BADLY_BROKEN_BOARD
	bool

and then wire the specific quirk to SPECIFIC_QUIRK_FOR_BADLY_BROKEN_BOARD 
rather than PCI_QUIRKS in the Makefile system.

 Thank you for your input.

  Maciej

  parent reply	other threads:[~2022-09-17 13:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06 15:09 [PATCH] pci: Do not enable PCIe ASMedia ASM2824 workaround by default Pali Rohár
2022-04-07  6:33 ` Stefan Roese
2022-04-07 23:18   ` Maciej W. Rozycki
2022-05-01 15:18     ` Pali Rohár
2022-05-05 11:46       ` Maciej W. Rozycki
2022-05-14 13:20         ` Maciej W. Rozycki
2022-08-27 12:30 ` [PATCH v2] pci: Do not enable PCIe GEN3 link retrain " Pali Rohár
2022-08-30  2:30   ` Simon Glass
2022-08-30  9:04   ` Maciej W. Rozycki
2022-08-30  9:19     ` Pali Rohár
2022-08-30 11:15       ` Stefan Roese
2022-08-30 11:56         ` Pali Rohár
2022-09-17 13:03           ` Maciej W. Rozycki
2022-09-17 13:02         ` Maciej W. Rozycki [this message]
2022-09-17 13:02       ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2209171342020.53071@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=bmeng.cn@gmail.com \
    --cc=pali@kernel.org \
    --cc=sjg@chromium.org \
    --cc=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).