On Fri, Jul 13, 2012 at 9:04 PM, Chris Webb <[email protected]> wrote:
> Commit c2c20ef43d00 "bnx2: Update driver to use new mips firmware"
> updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of
> bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a
> in firmware/bnx2/ with the new version.
>
> This means that the bnx2 driver stopped working altogether for users who
> use CONFIG_FIRMWARE_IN_KERNEL to compile firmware together with drivers
> into their kernel, rather than having a runtime firmware loader.
>
Still not fixed in mainline? I encountered the same problem with
v3.6-rc1-133-g42a579a.
From: Jike Song <[email protected]>
Date: Wed, 8 Aug 2012 13:50:42 +0800
> On Fri, Jul 13, 2012 at 9:04 PM, Chris Webb <[email protected]> wrote:
>> Commit c2c20ef43d00 "bnx2: Update driver to use new mips firmware"
>> updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of
>> bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a
>> in firmware/bnx2/ with the new version.
>>
>> This means that the bnx2 driver stopped working altogether for users who
>> use CONFIG_FIRMWARE_IN_KERNEL to compile firmware together with drivers
>> into their kernel, rather than having a runtime firmware loader.
>>
>
> Still not fixed in mainline? I encountered the same problem with
> v3.6-rc1-133-g42a579a.
The current firmware for all drivers are not distributed in the kernel
sources any longer, they are maintained in a completely seperate
repository.
The old ones are just kept around in the kernel sources for
compatability.
This is a FAQ.
On Tue, Aug 07, 2012 at 10:58:00PM -0700, David Miller wrote:
> From: Jike Song <[email protected]>
> Date: Wed, 8 Aug 2012 13:50:42 +0800
>
> > On Fri, Jul 13, 2012 at 9:04 PM, Chris Webb <[email protected]> wrote:
> >> Commit c2c20ef43d00 "bnx2: Update driver to use new mips firmware"
> >> updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of
> >> bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a
> >> in firmware/bnx2/ with the new version.
> >>
> >> This means that the bnx2 driver stopped working altogether for users who
> >> use CONFIG_FIRMWARE_IN_KERNEL to compile firmware together with drivers
> >> into their kernel, rather than having a runtime firmware loader.
> >>
> >
> > Still not fixed in mainline? I encountered the same problem with
> > v3.6-rc1-133-g42a579a.
>
> The current firmware for all drivers are not distributed in the kernel
> sources any longer, they are maintained in a completely seperate
> repository.
>
> The old ones are just kept around in the kernel sources for
> compatability.
>
> This is a FAQ.
Well, if the drivers provided with the kernel don't work out of the box
anymore, maybe we should also move them to a separate repository. All it
is going to do otherwise is to cause invalid bug reports because users
don't understand why using the latest driver does not work.
That way it would be clear that an in-kernel driver has to be self-sustaining
to be maintainable, otherwise it has nothing to do there.
Just my 2 cents,
Willy
On Wed, 2012-08-08 at 08:17 +0200, Willy Tarreau wrote:
>
> Well, if the drivers provided with the kernel don't work out of the box
> anymore, maybe we should also move them to a separate repository. All it
> is going to do otherwise is to cause invalid bug reports because users
> don't understand why using the latest driver does not work.
>
> That way it would be clear that an in-kernel driver has to be self-sustaining
> to be maintainable, otherwise it has nothing to do there.
People compiling their own kernels are supposed to be able to handle
this problem themselves.
If not, they can use a distro.
Hi Eric,
On Wed, Aug 08, 2012 at 08:27:52AM +0200, Eric Dumazet wrote:
> On Wed, 2012-08-08 at 08:17 +0200, Willy Tarreau wrote:
>
> >
> > Well, if the drivers provided with the kernel don't work out of the box
> > anymore, maybe we should also move them to a separate repository. All it
> > is going to do otherwise is to cause invalid bug reports because users
> > don't understand why using the latest driver does not work.
> >
> > That way it would be clear that an in-kernel driver has to be self-sustaining
> > to be maintainable, otherwise it has nothing to do there.
>
> People compiling their own kernels are supposed to be able to handle
> this problem themselves.
>
> If not, they can use a distro.
But similarly, people who compile their own kernels are also supposed to
be able to retrieve up-to-date drivers from another tree. I know many
people who use the intel NIC drivers from sf.net and (less) other ones
using myricom's drivers for instance.
I don't really see the value of keeping in the tree drivers that don't
work out of the box, if it's only causing issues and bug reports.
Regards,
Willy
On Wed, 2012-08-08 at 08:49 +0200, Willy Tarreau wrote:
> Hi Eric,
>
> On Wed, Aug 08, 2012 at 08:27:52AM +0200, Eric Dumazet wrote:
> > On Wed, 2012-08-08 at 08:17 +0200, Willy Tarreau wrote:
> >
> > >
> > > Well, if the drivers provided with the kernel don't work out of the box
> > > anymore, maybe we should also move them to a separate repository. All it
> > > is going to do otherwise is to cause invalid bug reports because users
> > > don't understand why using the latest driver does not work.
> > >
> > > That way it would be clear that an in-kernel driver has to be self-sustaining
> > > to be maintainable, otherwise it has nothing to do there.
> >
> > People compiling their own kernels are supposed to be able to handle
> > this problem themselves.
> >
> > If not, they can use a distro.
>
> But similarly, people who compile their own kernels are also supposed to
> be able to retrieve up-to-date drivers from another tree. I know many
> people who use the intel NIC drivers from sf.net and (less) other ones
> using myricom's drivers for instance.
>
> I don't really see the value of keeping in the tree drivers that don't
> work out of the box, if it's only causing issues and bug reports.
Only the firmware is in a separate git tree, called linux-firmware, that
about all kernel developers are aware of.
The drivers themselves are in linux tree, and they are generally in
quite good shape, because of that.