[PATCH v2] pci: Work around PCIe link training failures

[Maciej W. Rozycki]

Hi Stefan,

> > > I would like to hear what Bjorn Helgaas thinks about this issue at all
> > > and how to handle it, without potentially break something else. And
> > > based on the fact that in U-Boot's PCI core code there is no such global
> > > quirk implemented, I really do not know if U-Boot maintainers and
> > > developers want to review and understand all PCI Express aspect of this
> > > code and possible side-effects. This is just what I think about it, I do
> > > not have maintainer hat.
> > 
> >   Please leave the decision up to actual maintainers then.  They can speak
> > for themselves.
> 
> Sure, this is correct. But still, review comments from other developers
> (e.g. non maintainers) are often very helpful. And especially Pali has
> done quite a lot of work in the area of PCIe lately (amongst others) and
> IMHO his thoughts and comments seem quite reasonable - at least to me.

 Having done it myself I know reviews are often more challenging than 
actual problem solving, also from my own experience, and I do appreciate 
Pali's effort and the willingness to help, as I have already expressed.  

> > > And... I have also PCIe HW which does not support DLLA bit and RL bit is
> > > write-only. I'm not sure right now, if this code would not cause issues
> > > for such HW (if to it is connected broken PCIe card which does not like
> > > link retraining), this needs to be tested.
> > 
> >   RL is always write-only and DLLLA is often not supported.  I think both
> > code itself and my description is clear as to the handling of these bits.
> > 
> >   Are you sure you are up to reviewing code in this area?
> 
> Maciej, please don't get me wrong. I value your input here. But this
> sounds a bit offensive IMHO and I would like to keep the discussion here
> on the technical level.

 Apologies to sound a little harsh.

 I've started feeling being side-tracked into non-issues though, as some 
of the matters raised are clear either from the specification or I have 
specifically pointed them out with my submission, e.g.:

"Use the Data Link Layer Link Active status flag as the primary indicator 
of successful link speed negotiation, but given that the flag is optional 
by hardware to implement (the ASM2824 does have it though) [...]"

(previously also the matter with the Supported Link Speeds Vector, etc.), 
so I started feeling like my effort to get all the details given in the 
submission was for nothing.

 Thank you for your input.

  Maciej