lkml.org 
[lkml]   [2008]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: bcm43xx regression in 2.6.24 (with patch)
    Date
    On Wednesday 27 February 2008 01:23:17 Alexey Zaytsev wrote:
    > On Wed, Feb 27, 2008 at 1:47 AM, John W. Linville
    > <linville@tuxdriver.com> wrote:
    > > On Wed, Feb 27, 2008 at 01:12:32AM +0300, Alexey Zaytsev wrote:
    > > > On Wed, Feb 27, 2008 at 1:04 AM, Michael Buesch <mb@bu3sch.de> wrote:
    > >
    > >
    > > > > Besides that the bcm43xx driver is not broken. That's the whole reason
    > > > > this damn thread started at all. So it can't be broken.
    > > > >
    > > > Can't agree here. The bcm43xx driver used to work with 2.6.23 without requiring
    > > > any module magic.
    > >
    > > At the risk of prolonging things... :-(
    > >
    > > Isn't the fundamental problem here that the ssb driver claims the same
    > > PCI IDs as the bcm43xx driver? He have hit this same issue a number
    > > of times: 8139too vs. 8139cp, eepro vs. e100, sk98lin vs. skge,
    > > and I'm sure there are more. I admit that this situation is a bit
    > > more confusing, since the user is less likely to predict a conflict
    > > between bcm43xx and the ssb driver. This is especially true since
    > > the user isn't even selecting ssb directly, but is instead selecting
    > > the apparently unrelated b44.
    > >
    > > Still, the bcm43xx driver is not fundamentally damaged. This is
    > > fundamentally a "two drivers claiming the same PCI ID" issue, not a
    > > "you broke my driver" one.
    >
    > Is there any reason the ssb driver should claim the bcm43xx pci ids in
    > the first place? I have very little understanding what the Sonic Silicon
    > Backplane really is, but I see that the b44 driver claims its PCI ids
    > directly. I also think I understand why the b43/b43legacy drivers can't
    > claim the ids directly: because the driver-device matching is done not
    > with the pci bus methods, but with the ssb bus methods, and it would
    > be impossible to automatically choose the right driver for the right
    > device (with same ssb ids), as the first of the two drivers loaded would
    > succeed in probe()'ing the pci "ssb bridge" device, and not letting the
    > other to take control, even after moments later the ssb probe for the
    > non-supported ssb device would fail. (Or am I completely wrong?)
    >
    > That said, I still think that the ssb driver claims the wrong pci ids,
    > which is especially wrong if the the b43/b43legacy drivers are not
    > even built. And my patch fixes exactly this problem - the ssb driver
    > no more claims the broadcom pci ids, when the b43/b43legacy drivers
    > are not built.
    >
    > One better solution I think might be to move the b43_pci_bridge.c
    > code to a separate module, and let the b43/b43legacy drivers
    > depend on it, but as I said, I have little knowledge in the
    > ssb stuff, so I did it the easy way.

    See the comment in b43_pci_bridge.c

    --
    Greetings Michael.


    \
     
     \ /
      Last update: 2008-02-27 01:31    [W:0.022 / U:29.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site