post-2.6.14 USB change breaks sparc64 boot

post-2.6.14 USB change breaks sparc64 boot

[David S. Miller]

This change:

diff-tree 478a3bab8c87a9ba4a4ba338314e32bb0c378e62 (from 46f116eab81b21c6ae8c4f169498c632b1f94bf1)
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Oct 19 12:52:02 2005 -0400

    [PATCH] USB: Always do usb-handoff
    
    This revised patch (as586b) makes usb-handoff permanently true and no
    longer a kernel boot parameter.  It also removes the piix3_usb quirk code;
    that was nothing more than an early version of the USB handoff code
    (written at a time when Intel's PIIX3 was about the only motherboard with
    USB support).  And it adds identifiers for the three PCI USB controller
    classes to pci_ids.h.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

breaks sparc64 bootup badly on machines with USB host controllers.

The reason is that this fixup is run as a PCI header fixup, but at
that time it is not yet legal to do ioremap() on the PCI device's
resources.  This USB fixup does ioremap() calls so that it can program
a few of the host controller registers during bootup.  It fails
spectacularly since the PCI device resource values haven't been been
adjusted by the sparc64 PCI layer yet.

The platform layer first needs a chance to fixup the pdev->resource[]
values to the format the ioremap() expects, and this is done after the
PCI header fixups are executed.  On platforms where this matters, such
adjustments are made immediately after the pci_scan_bus() invocation.

So ioremap() calls during pci_scan_bus() are pretty much not allowed.

Perhaps pci_fixup_final would be a more appropriate time to run this
USB host controller fixup?  One downside to this is that such calls
would not be invoked for hot-plugged USB host controller devices.

Re: post-2.6.14 USB change breaks sparc64 boot

[Maciej W. Rozycki]

On Thu, 3 Nov 2005, David S. Miller wrote:

> Perhaps pci_fixup_final would be a more appropriate time to run this
> USB host controller fixup?  One downside to this is that such calls
> would not be invoked for hot-plugged USB host controller devices.

 This might actually want to be split to disable legacy stuff as soon as
possible to prevent a flood of interrupts, sending SMIs and what not else.  
That just requires poking at the PCI config space.  Whatever's the rest
could be done later.  I guess hot-plugged USB host controllers are not
configured for legacy support, so the early bits should not matter for
them.

  Maciej

Re: post-2.6.14 USB change breaks sparc64 boot

[Alan Stern]

On Thu, 3 Nov 2005, Maciej W. Rozycki wrote:

> On Thu, 3 Nov 2005, David S. Miller wrote:
> 
> > Perhaps pci_fixup_final would be a more appropriate time to run this
> > USB host controller fixup?  One downside to this is that such calls
> > would not be invoked for hot-plugged USB host controller devices.
> 
>  This might actually want to be split to disable legacy stuff as soon as
> possible to prevent a flood of interrupts, sending SMIs and what not else.  
> That just requires poking at the PCI config space.  Whatever's the rest
> could be done later.  I guess hot-plugged USB host controllers are not
> configured for legacy support, so the early bits should not matter for
> them.

See this email thread:

http://marc.theaimsgroup.com/?l=linux-kernel&m=113081793516723&w=2

Alan Stern

Re: post-2.6.14 USB change breaks sparc64 boot

[Maciej W. Rozycki]

On Thu, 3 Nov 2005, Alan Stern wrote:

> >  This might actually want to be split to disable legacy stuff as soon as
> > possible to prevent a flood of interrupts, sending SMIs and what not else.  
> > That just requires poking at the PCI config space.  Whatever's the rest
> > could be done later.  I guess hot-plugged USB host controllers are not
> > configured for legacy support, so the early bits should not matter for
> > them.
> 
> See this email thread:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113081793516723&w=2

 Hmm, how does this relate to my suggestion?  Apart from me having to note
that I have a MIPS-based system with an UHCI -- so these HCs are not
completely limited to Intel-based systems.  Though, unsurprisingly, it
doesn't use any of the legacy crap.  SMI from the south bridge is routed
to somewhere IIRC; probably an ordinary interrupt (and happily ignored).

  Maciej

Re: post-2.6.14 USB change breaks sparc64 boot

[Alan Stern]

On Thu, 3 Nov 2005, Maciej W. Rozycki wrote:

> On Thu, 3 Nov 2005, Alan Stern wrote:
> 
> > >  This might actually want to be split to disable legacy stuff as soon as
> > > possible to prevent a flood of interrupts, sending SMIs and what not else.  
> > > That just requires poking at the PCI config space.  Whatever's the rest
> > > could be done later.  I guess hot-plugged USB host controllers are not
> > > configured for legacy support, so the early bits should not matter for
> > > them.
> > 
> > See this email thread:
> > 
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=113081793516723&w=2
> 
>  Hmm, how does this relate to my suggestion?  Apart from me having to note
> that I have a MIPS-based system with an UHCI -- so these HCs are not
> completely limited to Intel-based systems.  Though, unsurprisingly, it
> doesn't use any of the legacy crap.  SMI from the south bridge is routed
> to somewhere IIRC; probably an ordinary interrupt (and happily ignored).

It's not particularly related to your suggestion, but it is related to the 
preceding email.  I just replied to the latest message in the thread to 
make sure that my reply was sent to anyone who might be interested, that's 
all.

In any case, I'm not so sure to what extent you can separate out the
disable-legacy stuff from the rest.  It's not good enough to disable
interrupt generation and bus-mastering; some controllers don't like it if
you do that while they are running.  It's necessary to shut the controller
down first.  And it looks like the code does just that -- there's not much 
else to separate out.

Alan Stern

Re: post-2.6.14 USB change breaks sparc64 boot

[David S. Miller]

From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Thu, 3 Nov 2005 17:46:20 +0000 (GMT)

> On Thu, 3 Nov 2005, David S. Miller wrote:
> 
> > Perhaps pci_fixup_final would be a more appropriate time to run this
> > USB host controller fixup?  One downside to this is that such calls
> > would not be invoked for hot-plugged USB host controller devices.
> 
>  This might actually want to be split to disable legacy stuff as soon as
> possible to prevent a flood of interrupts, sending SMIs and what not else.  
> That just requires poking at the PCI config space.  Whatever's the rest
> could be done later.  I guess hot-plugged USB host controllers are not
> configured for legacy support, so the early bits should not matter for
> them.

Would anyone mind if I pushed to Linus the following fix, at
least for now?  Thanks.

diff-tree 834843a8562e6614768d8c8b8a23d94d98af7360 (from 06024f217d607369f0ee0071034ebb03071d5fb2)
Author: David S. Miller <davem@sunset.davemloft.net>
Date:   Fri Nov 4 09:38:18 2005 -0800

    [USB]: Make early handoff a final fixup instead of a header one.
    
    At header fixup time, it is not yet legal to ioremap() PCI
    device registers, yet that is what this quirk code needs to
    do.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index b1aa350..e46528c 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -316,4 +316,4 @@ static void __devinit quirk_usb_early_ha
 	else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
 		quirk_usb_disable_ehci(pdev);
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);

Re: post-2.6.14 USB change breaks sparc64 boot

[Greg KH]

On Fri, Nov 04, 2005 at 09:40:53AM -0800, David S. Miller wrote:
> From: "Maciej W. Rozycki" <macro@linux-mips.org>
> Date: Thu, 3 Nov 2005 17:46:20 +0000 (GMT)
> 
> > On Thu, 3 Nov 2005, David S. Miller wrote:
> > 
> > > Perhaps pci_fixup_final would be a more appropriate time to run this
> > > USB host controller fixup?  One downside to this is that such calls
> > > would not be invoked for hot-plugged USB host controller devices.
> > 
> >  This might actually want to be split to disable legacy stuff as soon as
> > possible to prevent a flood of interrupts, sending SMIs and what not else.  
> > That just requires poking at the PCI config space.  Whatever's the rest
> > could be done later.  I guess hot-plugged USB host controllers are not
> > configured for legacy support, so the early bits should not matter for
> > them.
> 
> Would anyone mind if I pushed to Linus the following fix, at
> least for now?  Thanks.

No objection from me, if this fixes your machines.

> diff-tree 834843a8562e6614768d8c8b8a23d94d98af7360 (from 06024f217d607369f0ee0071034ebb03071d5fb2)
> Author: David S. Miller <davem@sunset.davemloft.net>
> Date:   Fri Nov 4 09:38:18 2005 -0800
> 
>     [USB]: Make early handoff a final fixup instead of a header one.
>     
>     At header fixup time, it is not yet legal to ioremap() PCI
>     device registers, yet that is what this quirk code needs to
>     do.
>     
>     Signed-off-by: David S. Miller <davem@davemloft.net>

Acked-by: Greg Kroah-Hartman <gregkh@suse.de>

Re: post-2.6.14 USB change breaks sparc64 boot

[Alan Stern]

On Fri, 4 Nov 2005, Greg KH wrote:

> On Fri, Nov 04, 2005 at 09:40:53AM -0800, David S. Miller wrote:
> > From: "Maciej W. Rozycki" <macro@linux-mips.org>
> > Date: Thu, 3 Nov 2005 17:46:20 +0000 (GMT)
> > 
> > > On Thu, 3 Nov 2005, David S. Miller wrote:
> > > 
> > > > Perhaps pci_fixup_final would be a more appropriate time to run this
> > > > USB host controller fixup?  One downside to this is that such calls
> > > > would not be invoked for hot-plugged USB host controller devices.
> > > 
> > >  This might actually want to be split to disable legacy stuff as soon as
> > > possible to prevent a flood of interrupts, sending SMIs and what not else.  
> > > That just requires poking at the PCI config space.  Whatever's the rest
> > > could be done later.  I guess hot-plugged USB host controllers are not
> > > configured for legacy support, so the early bits should not matter for
> > > them.
> > 
> > Would anyone mind if I pushed to Linus the following fix, at
> > least for now?  Thanks.
> 
> No objection from me, if this fixes your machines.

It's okay with me -- I think.  The real requirement is that this code 
needs to run before any devices that share an IRQ with a USB controller 
can have their IRQ handler registered.  That may not always be possible, 
but we should come as close as we can.

Hot-plugged controllers don't matter, because this code only needs to 
handle hardware that the BIOS may have initialized.

Alan Stern

Re: post-2.6.14 USB change breaks sparc64 boot

[Greg KH]

On Thu, Nov 03, 2005 at 09:33:28AM -0800, David S. Miller wrote:
> 
> This change:
> 
> diff-tree 478a3bab8c87a9ba4a4ba338314e32bb0c378e62 (from 46f116eab81b21c6ae8c4f169498c632b1f94bf1)
> Author: Alan Stern <stern@rowland.harvard.edu>
> Date:   Wed Oct 19 12:52:02 2005 -0400
> 
>     [PATCH] USB: Always do usb-handoff
>     
>     This revised patch (as586b) makes usb-handoff permanently true and no
>     longer a kernel boot parameter.  It also removes the piix3_usb quirk code;
>     that was nothing more than an early version of the USB handoff code
>     (written at a time when Intel's PIIX3 was about the only motherboard with
>     USB support).  And it adds identifiers for the three PCI USB controller
>     classes to pci_ids.h.
>     
>     Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> breaks sparc64 bootup badly on machines with USB host controllers.

Does Linus's current tree fix this?  I ask, because I thought that:

Author: Linus Torvalds <torvalds@g5.osdl.org>  2005-10-31 21:12:40
Committer: Linus Torvalds <torvalds@g5.osdl.org>  2005-10-31 21:12:40
Parent: 1e4c85f97fe26fbd70da12148b3992c0e00361fd (Revert "i386: move apic init in init_IRQs")
Child:  df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 (Merge git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs-2.6)

    Don't touch USB controller IO registers when they are disabled
    
    The USB "handoff" code is an early PCI quirk to make sure we own the USB
    controller (as opposed to the BIOS/SMM).  But if the controller isn't
    even enabled yet, don't try to access it.
    
    Acked-by: Paul Mackerras <paulus@samba.org> (who had an alternate patch)
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>


Should have fixed this.  If not, please let me know.

thanks,

greg k-h