backport fails for brcmfmac

backport fails for brcmfmac

[Arend van Spriel]

I rebased our internel backports tree to backports/master and now I get 
the following build error when backporting to 3.13 kernel:

/tmp/brcm-backports-gb8d29dc/drivers/net/wireless/brcm80211/brcmfmac/p2p.c:2315:11: 
error: ���struct net_device��� has no member named ���name_assign_type���
   ifp->ndev->name_assign_type = name_assign_type;

Obviously struct netdevice does not have name_assign_type in older 
kernels, ie. kernels < 3.17 looking at 
backport-include/linux/netdevice.h. Just not sure what made this issue 
come up. The assignment was introduced by:

commit 6bab2e19c5ffd1f21b28c2cabb3801a37b77ae69
Author: Tom Gundersen <teg@jklm.no>
Date:   Wed Mar 18 11:13:39 2015 +0100

     cfg80211: pass name_assign_type to rdev_add_virtual_intf()

Probably need to rework brcmfmac code to avoid the assignment and pass 
the name_assign_type to the alloc_netdev call. If there is an easier way 
feel free to let me know.

Regards,
Arend

Re: backport fails for brcmfmac

[Hauke Mehrtens]

On 04/12/2015 07:18 PM, Arend van Spriel wrote:
> I rebased our internel backports tree to backports/master and now I get
> the following build error when backporting to 3.13 kernel:
> 
> /tmp/brcm-backports-gb8d29dc/drivers/net/wireless/brcm80211/brcmfmac/p2p.c:2315:11:
> error: ���struct net_device��� has no member named ���name_assign_type���
>   ifp->ndev->name_assign_type = name_assign_type;
> 
> Obviously struct netdevice does not have name_assign_type in older
> kernels, ie. kernels < 3.17 looking at
> backport-include/linux/netdevice.h. Just not sure what made this issue
> come up. The assignment was introduced by:
> 
> commit 6bab2e19c5ffd1f21b28c2cabb3801a37b77ae69
> Author: Tom Gundersen <teg@jklm.no>
> Date:   Wed Mar 18 11:13:39 2015 +0100
> 
>     cfg80211: pass name_assign_type to rdev_add_virtual_intf()
> 
> Probably need to rework brcmfmac code to avoid the assignment and pass
> the name_assign_type to the alloc_netdev call. If there is an easier way
> feel free to let me know.

I think this name_assign_type member is only used to show how the device
name was assigned to the device. See name_assign_type in
Documentation/ABI/testing/sysfs-class-net
On kernel versions which do not support this sysfs entry, we can just
ignore this new member. I think it is save to just add an "#if linux >=
3.17" around this assignment.

Hauke

Re: backport fails for brcmfmac

[Arend van Spriel]

On 04/12/15 21:55, Hauke Mehrtens wrote:
> On 04/12/2015 07:18 PM, Arend van Spriel wrote:
>> I rebased our internel backports tree to backports/master and now I get
>> the following build error when backporting to 3.13 kernel:
>>
>> /tmp/brcm-backports-gb8d29dc/drivers/net/wireless/brcm80211/brcmfmac/p2p.c:2315:11:
>> error: ���struct net_device��� has no member named ���name_assign_type���
>>    ifp->ndev->name_assign_type = name_assign_type;
>>
>> Obviously struct netdevice does not have name_assign_type in older
>> kernels, ie. kernels<  3.17 looking at
>> backport-include/linux/netdevice.h. Just not sure what made this issue
>> come up. The assignment was introduced by:
>>
>> commit 6bab2e19c5ffd1f21b28c2cabb3801a37b77ae69
>> Author: Tom Gundersen<teg@jklm.no>
>> Date:   Wed Mar 18 11:13:39 2015 +0100
>>
>>      cfg80211: pass name_assign_type to rdev_add_virtual_intf()
>>
>> Probably need to rework brcmfmac code to avoid the assignment and pass
>> the name_assign_type to the alloc_netdev call. If there is an easier way
>> feel free to let me know.
>
> I think this name_assign_type member is only used to show how the device
> name was assigned to the device. See name_assign_type in
> Documentation/ABI/testing/sysfs-class-net
> On kernel versions which do not support this sysfs entry, we can just
> ignore this new member. I think it is save to just add an "#if linux>=
> 3.17" around this assignment.

Well. I don't want to do that upstream so that would mean adding a patch 
in backports that needs to be maintained which I prefer to avoid. I will 
see whether I can rework the code.

Regards,
Arend