Jeff/Roland,
I'm resubmitting the cxgb3 dev->priv fix for inclusion in 2.6.23.
I also submit a follow-up patch for the iw_cxgb3 driver that fixes
the previous infiniband breakage.
Cheers,
Divy
Looks OK to me but I would just roll up the second patch into the
first patch and let Jeff merge it as one commit. There's no point in
creating an intermediate tree that doesn't build -- it just breaks git
bisect for no useful purpose.
Also as a side note, when trying to test this I got the message
could not load TP SRAM: unable to load t3a_protocol_sram-1.0.44.bin
and you guys seem to only have t3b protocol sram images on your web
site. Could you send me the t3a file (or swap out my T3A boards for
T3B boards ;)?
Thanks,
Roland
Roland Dreier wrote:
> Looks OK to me but I would just roll up the second patch into the
> first patch and let Jeff merge it as one commit. There's no point in
> creating an intermediate tree that doesn't build -- it just breaks git
> bisect for no useful purpose.
Agreed -- this needs to be in a single patch.
Jeff
Roland Dreier wrote:
>
> Looks OK to me but I would just roll up the second patch into the
> first patch and let Jeff merge it as one commit. There's no point in
> creating an intermediate tree that doesn't build -- it just breaks git
> bisect for no useful purpose.
>
Okay, Jeff agrees too, I'll do so.
> Also as a side note, when trying to test this I got the message
>
> could not load TP SRAM: unable to load t3a_protocol_sram-1.0.44.bin
>
> and you guys seem to only have t3b protocol sram images on your web
> site. Could you send me the t3a file (or swap out my T3A boards for
> T3B boards ;)?
>
I'd rather fix the driver then:
First, HW folks tell me that there is no need for engine
microcode update for T3A.
Moreover, there is a bug when the file name is constructed.
We have T3B and T3B2 board revs, the driver looks for
t3b_protocol_sram-1.0.44.bin for T3B2 boards and defaults to
t3a_protocol_sram-1.0.44.bin even for T3B boards.
I submitted a patch fixing this in netdev#upstream.
I should propose the fix for 2.6.23 instead.
Cheers,
Divy
Roland,
We'll work on upgrading you to T3B2 boards as well.
Stay tuned.
Steve.
Divy Le Ray wrote:
> Roland Dreier wrote:
>>
>> Looks OK to me but I would just roll up the second patch into the
>> first patch and let Jeff merge it as one commit. There's no point in
>> creating an intermediate tree that doesn't build -- it just breaks git
>> bisect for no useful purpose.
>>
>
> Okay, Jeff agrees too, I'll do so.
>
>> Also as a side note, when trying to test this I got the message
>>
>> could not load TP SRAM: unable to load t3a_protocol_sram-1.0.44.bin
>>
>> and you guys seem to only have t3b protocol sram images on your web
>> site. Could you send me the t3a file (or swap out my T3A boards for
>> T3B boards ;)?
>>
> I'd rather fix the driver then:
> First, HW folks tell me that there is no need for engine
> microcode update for T3A.
> Moreover, there is a bug when the file name is constructed.
> We have T3B and T3B2 board revs, the driver looks for
> t3b_protocol_sram-1.0.44.bin for T3B2 boards and defaults to
> t3a_protocol_sram-1.0.44.bin even for T3B boards.
> I submitted a patch fixing this in netdev#upstream.
> I should propose the fix for 2.6.23 instead.
>
> Cheers,
> Divy
>