Hi Andrew, On September 15, 2018 3:30:53 PM PDT, Andrew Lunn <and...@lunn.ch> wrote: >On Sat, Sep 15, 2018 at 02:31:14PM -0700, Florian Fainelli wrote: >> >> >> On 09/14/18 14:38, Andrew Lunn wrote: >> > This is one step in allowing phylib to make use of link_mode >bitmaps, >> > instead of u32 for supported and advertised features. Convert the >phy >> > drivers to use bitmaps to indicates the features they support. This >> > requires some macro magic in order to construct constant bitmaps >used >> > to initialise the driver structures. >> > >> > Some new PHY_*_FEATURES are added, to indicate FIBRE is supported, >and >> > that all media ports are supported. This is done since bitmaps >cannot >> > be ORed together at compile time. >> > >> > Within phylib, the features bitmap is currently turned back into a >> > u32. The MAC API to phylib needs to be cleaned up before the core >of >> > phylib can be converted to using bitmaps instead of u32. >> >> Nice! > >Hi Florian > >This is the patch i don't like. I'm hoping somebody can think of a >better way to initialise a bitmap.
By that you mean having to determine whether you overflow the capacity of an unsigned long storage type and having to put the bits in either unsigned long [0] or [1]? Being able to eliminate the duplication would also be nice, but I cannot think about a smart solution at compile time that would avoid doing that. -- Florian
