priv gone from struct net_device after 2.6.27; plans for wlan module?

1,048 views
Skip to first unread message

Jim Bray

unread,
Jun 7, 2009, 10:47:25 AM6/7/09
to Android Linux Kernel Development
I've been trying to build the wlan module so I can get a 2.6.29 kernel
running on my phone and still have the wifi work.

I have run into the following problem:

/big/android/mydroid/system/wlan/ti/sta_dk_4_0_4_32/./pform/linux/src/
osapi.c: In function 'os_sendPacket':
/big/android/mydroid/system/wlan/ti/sta_dk_4_0_4_32/./pform/linux/src/
osapi.c:1323: error: 'struct net_device' has no member named 'priv'

etcetcetc

Sometime after 2.6.27, the 'priv' member of struct net_device went
away, replaced with the function
netdev_priv().

I've been replacing uses of netdev->priv with things like:


static int setup_netif(tiwlan_net_dev_t *drv)
{
struct net_device *dev;
tiwlan_net_dev_t **priv;
int res;

#ifdef HAVE_NETDEV_PRIV
dev = alloc_etherdev(sizeof(tiwlan_net_dev_t *));
#else
dev = alloc_etherdev(0);
#endif

and

#ifdef HAVE_NETDEV_PRIV
drv = *(tiwlan_net_dev_t **)netdev_priv(dev);
#else
drv = (tiwlan_net_dev_t *)dev->priv;
#endif

and getting stuff to build,but I'm wondering how the Google developers
plan to handle this.
One approach would be to actually store the private information in the
netdev struct, which appears to be the desired practice. It appears at
present that this private information is being kept separately, so I
have looked at just keeping a pointer to the real private data in the
netdev private area, basically re-creating netdev->priv that way.

I could proceed along these lines, and produce some kind of patch,
but would like to see if this is wanted or if Google developers have
other plans. Already done esta_drv.c



pform/linux/src/esta_drv.c: drv = (tiwlan_net_dev_t *)dev->priv;
pform/linux/src/esta_drv.c: drv = (tiwlan_net_dev_t *)dev->priv;
pform/linux/src/esta_drv.c: drv = (tiwlan_net_dev_t *)dev->priv;
pform/linux/src/esta_drv.c: dev->priv = drv;
pform/linux/src/esta_drv.c: drv->priv = priv;
pform/linux/src/ioctl_list.c: res = tiwlan_start_drv
( (tiwlan_net_dev_t *)dev->priv );
pform/linux/src/ioctl_list.c: res = tiwlan_stop_drv
( (tiwlan_net_dev_t *)dev->priv );
pform/linux/src/ioctl_list.c: if ((req->cmd == TIWLN_SET_INIT_INFO) &&
(((tiwlan_net_dev_t *)dev->priv)->adapter.CoreHalCtx))
pform/linux/src/ioctl_list.c: res = tiwlan_init_drv
((tiwlan_net_dev_t *)dev->priv, init_info);
pform/linux/src/ioctl_list.c: res = tiwlan_profile_report
((tiwlan_net_dev_t *)dev->priv);
pform/linux/src/ioctl_list.c: res =
tiwlan_profile_cpu_usage_estimator_start((tiwlan_net_dev_t *)dev-
>priv,
pform/linux/src/ioctl_list.c: res =
tiwlan_profile_cpu_usage_estimator_stop((tiwlan_net_dev_t *)dev-
>priv);
pform/linux/src/ioctl_list.c: res
=tiwlan_profile_cpu_usage_estimator_reset((tiwlan_net_dev_t *)dev-
>priv);
pform/linux/src/ioctl_list.c: res = tiwlan_send_wait_reply
((tiwlan_net_dev_t *)dev->priv, ti1610_ioctl_priv_proc_tl,
pform/linux/src/ioctl_utils.c: ((dev && dev->priv) ?
((tiwlan_net_dev_t *) dev->priv)->adapter.CoreHalCtx : NULL ) )
pform/linux/src/osapi.c: tiwlan_net_dev_t *drv = (tiwlan_net_dev_t
*)dev->priv;
sta_dk_4_0_4_32$

Greg KH

unread,
Jun 7, 2009, 1:40:36 PM6/7/09
to android...@googlegroups.com
On Sun, Jun 7, 2009 at 7:47 AM, Jim Bray<jimsa...@gmail.com> wrote:
>
> I've been trying to build the wlan module so I can get a 2.6.29 kernel
> running on my phone and still have the wifi work.
>
>  I have run into the following problem:
>
> /big/android/mydroid/system/wlan/ti/sta_dk_4_0_4_32/./pform/linux/src/
> osapi.c: In function 'os_sendPacket':
> /big/android/mydroid/system/wlan/ti/sta_dk_4_0_4_32/./pform/linux/src/
> osapi.c:1323: error: 'struct net_device' has no member named 'priv'
>
> etcetcetc
>
>  Sometime after 2.6.27, the 'priv' member of struct net_device went
> away, replaced with the function
> netdev_priv().
>
>  I've been replacing uses of netdev->priv with things like:
>
>
> static int setup_netif(tiwlan_net_dev_t *drv)
> {
>    struct net_device *dev;
>    tiwlan_net_dev_t **priv;
>    int res;
>
> #ifdef HAVE_NETDEV_PRIV
>    dev = alloc_etherdev(sizeof(tiwlan_net_dev_t *));
> #else
>    dev = alloc_etherdev(0);
> #endif

Are you sure this is correct? It shouldn't be needed.

> and
>
> #ifdef HAVE_NETDEV_PRIV
>  drv = *(tiwlan_net_dev_t **)netdev_priv(dev);
> #else
>  drv = (tiwlan_net_dev_t *)dev->priv;
> #endif

You don't need the #ifdef, the changes you are making will also work on older
kernel versions.

Also, you don't need the cast.

> and getting stuff to build,but I'm wondering how the Google developers
> plan to handle this.
> One approach would be to actually store the private information in the
> netdev struct, which appears to be the desired practice.

Yes, that should be the way to do this.

What really needs to happen is this driver get merged into mainline and these
changes will be done for you.

If I get bored, I'll just dump the driver into the staging tree, but it should
be done by the original developers, and not rely on me to do it...

thanks,

greg k-h

Jim Bray

unread,
Jun 7, 2009, 3:44:30 PM6/7/09
to Android Linux Kernel Development


On Jun 7, 1:40 pm, Greg KH <gre...@gmail.com> wrote:
> On Sun, Jun 7, 2009 at 7:47 AM, Jim Bray<jimsante...@gmail.com> wrote:

> >  I've been replacing uses of netdev->priv with things like:
>
> > static int setup_netif(tiwlan_net_dev_t *drv)
> > {
> >    struct net_device *dev;
> >    tiwlan_net_dev_t **priv;
> >    int res;
>
> > #ifdef HAVE_NETDEV_PRIV
> >    dev = alloc_etherdev(sizeof(tiwlan_net_dev_t *));
> > #else
> >    dev = alloc_etherdev(0);
> > #endif
>
> Are you sure this is correct?  It shouldn't be needed.

I'm assuming based on usage elsewhere that the arg for
alloc_etherdev is the amount
of private data wanted. So I want space for a pointer there if I am
faking netdev->priv by
keeping a (real_private_data *) there. I'm assuming netdevs are
dynamically allocated and
not assuming there is any space tagged on for private_data unless it
is requested.

>
> > and
>
> > #ifdef HAVE_NETDEV_PRIV
> >  drv = *(tiwlan_net_dev_t **)netdev_priv(dev);
> > #else
> >  drv = (tiwlan_net_dev_t *)dev->priv;
> > #endif
>
> You don't need the #ifdef, the changes you are making will also work on older
> kernel versions.

I'm not sure of any of this, having only stumbled into it this
morning trying to get wlan.ko working with 2.6.29.
I did look thru the linux versions and found that netdev->priv did go
away after 2.6.27.
HAVE_NETDEV_PRIV is #defined in netdevice.h, so I thought I would use
it to demarcate my changes, It does
look like netdev_priv() went in quite a while ago, and they finally
killed netdev->priv with 2.6.28. So the ifdefs
would only help with a really ancient kernel, and everything else
would be broken there. Basically for decoration.

>
> Also, you don't need the cast.

Probably not, but it doesn't hurt anything. I wasn't proposing final
code. Netdev_priv() returns
void *, so might as well cast it, especially if I am using it as a **.
But I haven't written much code
in years; I could be way off. Compiled, anyway. I guess I would rather
comment by casting than
trust implicit conversions and then maybe comment about them.

>
> > and getting stuff to build,but I'm wondering how the Google developers
> > plan to handle this.
> > One approach would be to actually store the private information in the
> > netdev struct, which appears to be the desired practice.
>
> Yes, that should be the way to do this.

Unless (pure speculation) the private data is somehow tangled up
with the proprietary
binary htc modules. That could be a problem.

>
> What really needs to happen is this driver get merged into mainline and these
> changes will be done for you.
>
> If I get bored, I'll just dump the driver into the staging tree, but it should
> be done by the original developers, and not rely on me to do it...

So should I just wait and do a repo sync every now and then and
watch for changes?
I can get in and finish the edits for either case, having the private
data at the end of the
struct netdev, or just having a pointer to it there. In the former
case, someone who knows what this private
data is and who else is using it should probably take care of
initialising it.

Just let me know if I should proceed at all, or just wait. It would
be fun to get 2.6.29 fully working on my phone,
not that I need it or anything.

San Mehat

unread,
Jun 7, 2009, 3:56:59 PM6/7/09
to android...@googlegroups.com

Greg - please don't bother wasting your time if you're bored :). Bob Copeland (from the wireless folks) and I are working on moving to the wl12xx driver which is currently in wireless-testing.

Thanks :)

San (from my Dream)

On Jun 7, 2009 10:41 AM, "Greg KH" <gre...@gmail.com> wrote:

On Sun, Jun 7, 2009 at 7:47 AM, Jim Bray<jimsa...@gmail.com> wrote: > > I've been trying to buil...

Are you sure this is correct?  It shouldn't be needed.

> and > > #ifdef HAVE_NETDEV_PRIV >  drv = *(tiwlan_net_dev_t **)netdev_priv(dev); > #else >  drv =...

You don't need the #ifdef, the changes you are making will also work on older
kernel versions.

Also, you don't need the cast.

> and getting stuff to build,but I'm wondering how the Google developers > plan to handle this. > O...

Yes, that should be the way to do this.

What really needs to happen is this driver get merged into mainline and these
changes will be done for you.

If I get bored, I'll just dump the driver into the staging tree, but it should
be done by the original developers, and not rely on me to do it...

thanks,

greg k-h

--~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-kernel+unsubscribe@googl...

Jim Bray

unread,
Jun 7, 2009, 5:27:21 PM6/7/09
to Android Linux Kernel Development
Let me know if I can alpha-test or something. I have current 2.6.29
on the phone, just need a wlan.ko to try.

Jim


On Jun 7, 3:56 pm, San Mehat <s...@google.com> wrote:
> Greg - please don't bother wasting your time if you're bored :). Bob
> Copeland (from the wireless folks) and I are working on moving to the wl12xx
> driver which is currently in wireless-testing.
>
> Thanks :)
>
> San (from my Dream)
>
> On Jun 7, 2009 10:41 AM, "Greg KH" <gre...@gmail.com> wrote:
>
Reply all
Reply to author
Forward
0 new messages