Hi Steve,
I'm happy too with the result, but..
I did the test with the patch that Michael sent (with and without)
disabling the function ssb_pcicore_dev_irqvecs_enable following the
e-mails, without the same result. (Kernel 2.6.25.9-wl500gpv2).
Steve can you verify the modifications of the test, please, I want to
reproduce the result.
} //else
//ssb_pcicore_dev_irqvecs_enable(&sdev->bus->pcicore, sdev);
Thanks,
Fmay
On Fri, 2008-07-04 at 20:33 -0400, Steve Brown wrote:
> Forgot the cc's. And to close the thread.
>
> Michael Buesch wrote:
> > On Friday 04 July 2008 21:39:46 Steve Brown wrote:
> >
> >> Michael Buesch wrote:
> >>
> >>> On Tuesday 01 July 2008 21:50:43 Steve Brown wrote:
> >>>
> >>>
> >>>> It looks like (almost) every other phy register doesn't respond. I put
> >>>> in a large (200us) delay between accesses with no change in behaviour.
> >>>> If it is timing, it must be on the pci bus side of the core.
> >>>>
> >>>>
> >>> Ah this is a minipci card?
> >>> Can you try to play with the PCI bus timings that are initialised in
> >>> the PCI-core driver of SSB? See the function that initialises the
> >>> PCI-core in hostmode.
> >>>
> >>>
> >>>
> >> The problem is actually in b44. The ssb_pcicore_dev_irqvecs_enable call
> >> in b44_chip_enable at b44.c:1281 is the cause of the problem. It gets
> >> called unconditionally, even if the b44 is not on the pci. With it
> >> commented out, b43 loads, loads firmware and returns scan results.
> >>
> >> It crept in sometime after 2.6.23.1. I'm not familiar with b44 and can't
> >> offer a fix.
> >>
> >> I still don't understand how this caused the bus errors. Anybody got an
> >> explanation?
> >>
> >
> > So do you have a PCI bus on the system? Is the wireless connected via
> > minipci?
> >
> >
> >
>
> Yeah well. Probably a silicon glitch. We're not supposed
> to change the IRQ routing of the PCI core on the board, as the
> IRQs on the board are routed through the Mips core.
>
> Can you try the following patch?
> Please try ethernet and wireless. For wireless it's probably OK
> to try loading the driver. But I'd prefer if you try to scan the
> channels. That would probably be enough to make sure it works correctly.
>
> I'll immediately submit this for inclusion in mainline, if you report
> success.
> Thanks for testing.
>
>
> Index: wireless-testing/drivers/ssb/driver_pcicore.c
> ===================================================================
> --- wireless-testing.orig/drivers/ssb/driver_pcicore.c 2008-06-10
> 13:58:23.000000000 +0200
> +++ wireless-testing/drivers/ssb/driver_pcicore.c 2008-07-04
> 23:16:02.000000000 +0200
> @@ -537,6 +537,13 @@ int ssb_pcicore_dev_irqvecs_enable(struc
> int err = 0;
> u32 tmp;
>
> + if (dev->bus->bustype != SSB_BUSTYPE_PCI) {
> + /* This SSB device is not on a PCI host-bus. So the IRQs are
> + * not routed through the PCI core.
> + * So we must not enable routing through the PCI core. */
> + goto out;
> + }
> +
> if (!pdev)
> goto out;
> bus = pdev->bus;
>
> ----------------------------
> The bug is fixed!
>
> The b43 driver now loads, loads firmware and returns scan results.
>
> Thanks,
>
> Steve
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
