Hi,

apparently the driver has gained actual support for LP-PHY based devices
since, so not reopening bug.

> also this seems just user error just blacklist said module

I disagree. It is not a "user error" if a kernel module is loaded for a
piece of hardware because it declares support for the hardware in its
device table, and subsequently fails to initialize because it does not
actually support the hardware.

> if you prefer to use out of tree binary junk.

It certainly wasn't preference.

> fail to see a bug here.

The bug at that point in time was that an entry was added to the device
table that could not ever work because the probe function explicitly
rejected the device.

Simon



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sat, Feb 13, 2010 at 09:38:01PM +0100, Simon Richter wrote:
> > also this seems just user error just blacklist said module
> I disagree. It is not a "user error" if a kernel module is loaded for a
> piece of hardware because it declares support for the hardware in its
> device table, and subsequently fails to initialize because it does not
> actually support the hardware.

The b43 driver does not claim devices it does not know. However the
binary driver want to control the ssb bridge, which is a different
device.

Bastian

--
Deflector shields just came on, Captain.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi,

On Sat, Feb 13, 2010 at 11:21:51PM +0100, Bastian Blank wrote:

> The b43 driver does not claim devices it does not know.

Not anymore. It did at the time of the original bug report.

Simon



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100214235310.GB21715@honey.hogyros.de">http://lists.debian.org/20100214235310.GB21715@honey.hogyros.de