Re: [for-next 07/10] IB/mlx5: Use blue flame register allocator in mlx5_ib

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

On Sun, 2017-01-08 at 08:22 +0200, Leon Romanovsky wrote:
> On Fri, Jan 06, 2017 at 11:11:31AM -0500, David Miller wrote:
> > 
> > From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > Date: Fri, 6 Jan 2017 08:06:09 +0200
> > 
> > > 
> > > On Thu, Jan 05, 2017 at 03:07:31PM -0500, David Miller wrote:
> > > > 
> > > > From: Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
> > > > Date: Thu, 5 Jan 2017 14:03:18 -0600
> > > > 
> > > > > 
> > > > > If necessary I can make sure it builds on 32 bits as well.
> > > > 
> > > > Please do.
> > > 
> > > Dave,
> > > 
> > > I'm failing to understand the benefits of building mlx5 on 32
> > > bits, and
> > > see only disadvantages:
> > >  * It is actual dead code without test coverage.
> > >  * It misleads reviewers/customers by seeing code for 32 bits.
> > >  * It adds compilation time for 32 bits platforms and "punishes"
> > > them
> > >    for not relevant for them driver.
> > > 
> > > Why do you call removing all that as a "regression"?
> > 
> > We have this thing called "CONFIG_COMPILE_TEST", it has tons of
> > value,
> > perhaps you've seen it before?
> 
> Thanks David,
> I see your point.

What's the status update on this.  Unless I'm missing it in my rdma
mailing list (which is always possible if I scan subjects too fast), I
don't see a v2 of this pull request, but I also don't see that David's
concerns have been addressed, nor that he has pulled this.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]