alx - next round of review / portability comments

[Huang, Xiong]

Hi Adrian
    Thanks for your reviewing and suggestion !
    due to the re-org of IBU, I may not have much time on this driver, Ken Wu will continue its supporting.

BR.
Xiong

> -----Original Message-----
> From: unified-drivers [mailto:unified-drivers-bounces at lists.infradead.org] On
> Behalf Of Adrian Chadd
> Sent: Tuesday, April 09, 2013 3:45 AM
> To: unified-drivers at lists.infradead.org
> Subject: alx - next round of review / portability comments
> 
> Hiya!
> 
> I've spent a few days going back over the alx code to see how hard it'd be to
> bring up the hardware side of things in non-Linux.
> 
> It's in better shape than before.
> 
> The architectural (high level) overview:
> 
> * there's a mix of network stack facing and hardware specific code in both
> alx_main.c and alx_hw.c, which makes it hard to port.
> * the hardwre registers are in a separate header, but the transmit / receive
> descriptors are in alx_hw.h, which includes the linux specific netdev stuff.
> * alx_hw.c and alx_main.c have a variety of different things all glumped
> together - transmit/receive obviously, but there's also PHY related code, MDIO
> bus stuff, MAC setup/start/stop stuff, PCIe stuff, etc.
> 
> So what I'm thinking of doing:
> 
> * Separate out the hardware facing code from the driver facing code into two
> subdirectories for now - hw/ will have hardware specific code, drv/ will have
> the linux driver code;
> * drv/ will only call into hw/ to get things done - ie, there's no hardware code
> _in_ drv/ ;
> * split struct alx_hw into struct alx_hw and struct alx_hal (I know, I
> know) - move as much hardware state into alx_hal;
> * portability types / calls / etc only go into the code in hw/, not the code in drv/;
> * Make sure that works.
> 
> I don't think I'll be able to fully capture all of the hardware code in this split in
> the first pass - there's just too much stuff entwined with driver facing code. But
> it's a good start.
> 
> My aim is to get everything in hw/ compilable on non-Linux, so then I can
> (hopefully!) get device probe/attach/detach working on FreeBSD.
> 
> Comments?
> 
> 
> Adrian
> 
> _______________________________________________
> unified-drivers mailing list
> unified-drivers at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/unified-drivers