Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

[Zoran Stojsavljevic]

Pozaluista, vi zabud6te pro kernels 3.5... Takze rannih, takze pozzih. Mi v
dejateljnosti 4.0.+ Eto dolzen bit6 zakon!

(we need to bind/connect to kernels 4.1+... Don't we)?!

Zoran
_______

On Wed, Oct 11, 2017 at 9:49 AM, Аладышев Константин 
wrote:
> As I described earlier commit that solves my USB problem is 3d9545c and it
> was merged in kernel 3.5
>
> So in this terminology:
> Old kernels: <3.5
> Modern kernels: >=3.5
>
> From: Zoran Stojsavljevic [mailto:[e-mail]]
> Sent: Tuesday, October 10, 2017 8:03 PM
> To: Аладышев Константин
> Cc: coreboot
> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
> > Last time I was solving a problem of OS suspend-resume sequence with
>
> modern kernels and now it is about working with old kernels
>
> Hello Kostja,
>
> What is modern kernel, and what is old kernel? Any version/revision
> examples (you are using), so we can get the/some idea?
>
> Thank you,
> Zoran
> _______
>
> On Tue, Oct 10, 2017 at 10:14 AM, Аладышев Константин 
> wrote:
> Hello Zoran!
>
> Yes, I'm working with the same board, but the problem is different. Last
> time I was solving a problem of OS suspend-resume sequence with modern
> kernels and now it is about working with old kernels
>
> From: Zoran Stojsavljevic [mailto:[e-mail]]
> Sent: Tuesday, October 10, 2017 9:48 AM
> To: Аладышев Константин
> Cc: coreboot
> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
> Hello Kostja,
> We already had this discussion a while ago, didn't we?
>
> https://mail.coreboot.org/pipermail/coreboot/2016-December/082772.html
>
> (BTW, ATOM BYT has exactly the same problem)
>
> Zoran
>
> On Mon, Oct 9, 2017 at 11:58 AM, Аладышев Константин 
> wrote:
> I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset
> (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
> problem. USB devices stop working shortly after OS boot (or after USB
> device replug in OS) with flooding system with messages:
>
> hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: cannot reset
> port 5 (err = -110) hub 1-1:1.0: Cannot enable port 5.  Maybe the USB cable
> is bad?
> hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0:
> connect-debounce failed, port 5 disabled hub 1-1:1.0: unable to enumerate
> USB device on port 5 hub 1-1:1.0: cannot disable port 5 (err = -110) hub
> 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status
> failed (err = -110)
>
> Through some digging I've found out that this problem persist on kernels
> <3.5. I've investigated this problem more closely and come down to the fact
> that the kernel commit that solves this problem is:
>
> 3d9545c EHCI: maintain the ehci->command value properly
>
> https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf
> 9189c
> 62775?diff=split
>
> And now I'm kinda stuck. The effect of this commit doesn't seem to
> interface with bios for me. So how does original IBASE/DFI bios can
> overcome code error before this commit?
>
> What can be the source of my problem? What should I investigate more
> precise based on result that I've got?