[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OFC3760A10.997938DA-ONC12573A3.00077088-C12573A3.00089A9D@de.ibm.com>
Date: Fri, 30 Nov 2007 02:33:57 +0100
From: Peter Tiedemann <PTIEDEM@...ibm.com>
To: Stephen Hemminger <shemminger@...ux-foundation.org>
Cc: jgarzik@...ox.com, linux-s390@...r.kernel.org,
netdev@...r.kernel.org, Ursula Braun1 <braunu@...ibm.com>
Subject: Re: [patch 1/1] ctc: make use of alloc_netdev()
To maintain the area used for sysfs attribute data which may be stored
already previously.
Mit freundlichen Grüßen / Best regards / Saluti,
Peter Tiedemann
---------------------------------
phone: +49-7031-16-4172 fax: ++3159 e-mail: PTiedem@...ibm.com
IBM Deutschland Entwicklung GmbH
Linux for eServer Development, Dept. 3303
Schoenaicher Str. 220
71032 Boeblingen, Germany
IBM Deutschland Entwicklung GmbH, Vorsitzender des Aufsichtsrats: Martin
Jetter, Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen, Registergericht: Amtsgericht Stuttgart,
HRB 243294
Stephen Hemminger
<shemminger@...ux
-foundation.org> To
Ursula Braun1/Germany/IBM@...DE
29.11.2007 18:12 cc
jgarzik@...ox.com,
netdev@...r.kernel.org,
linux-s390@...r.kernel.org, Peter
Tiedemann/Germany/IBM@...DE
Subject
Re: [patch 1/1] ctc: make use of
alloc_netdev()
On Thu, 29 Nov 2007 17:36:27 +0100
Ursula Braun <braunu@...ibm.com> wrote:
> From: Peter Tiedemann <ptiedem@...ibm.com>
>
> Currently ctc-device initialization is broken (kernel bug in
> ctc_new_device).
> The new network namespace code reveals a deficiency of the
> ctc driver. It should make use of alloc_netdev() as described
> in Documentation/networking/netdevices.txt.
>
> Signed-off-by: Peter Tiedemann <ptiedem@...ibm.com>
> Signed-off-by: Ursula Braun <braunu@...ibm.com>
> ---
> drivers/s390/net/ctcmain.c | 45
++++++++++++++++-----------------------------
> 1 file changed, 16 insertions(+), 29 deletions(-)
>
> Index: linux-2.6-uschi/drivers/s390/net/ctcmain.c
> ===================================================================
> --- linux-2.6-uschi.orig/drivers/s390/net/ctcmain.c
> +++ linux-2.6-uschi/drivers/s390/net/ctcmain.c
> @@ -2782,35 +2782,14 @@ ctc_probe_device(struct ccwgroup_device
> }
>
> /**
> - * Initialize everything of the net device except the name and the
> - * channel structs.
> + * Device setup function called by alloc_netdev().
> + *
> + * @param dev Device to be setup.
> */
> -static struct net_device *
> -ctc_init_netdevice(struct net_device * dev, int alloc_device,
> - struct ctc_priv *privptr)
> +void ctc_init_netdevice(struct net_device * dev)
> {
> - if (!privptr)
> - return NULL;
> -
> DBF_TEXT(setup, 3, __FUNCTION__);
>
> - if (alloc_device) {
> - dev = kzalloc(sizeof(struct net_device),
GFP_KERNEL);
> - if (!dev)
> - return NULL;
> - }
> -
> - dev->priv = privptr;
> - privptr->fsm = init_fsm("ctcdev", dev_state_names,
> - dev_event_names,
CTC_NR_DEV_STATES, CTC_NR_DEV_EVENTS,
> - dev_fsm, DEV_FSM_LEN,
GFP_KERNEL);
> - if (privptr->fsm == NULL) {
> - if (alloc_device)
> - kfree(dev);
> - return NULL;
> - }
> - fsm_newstate(privptr->fsm, DEV_STATE_STOPPED);
> - fsm_settimer(privptr->fsm, &privptr->restart_timer);
> if (dev->mtu == 0)
> dev->mtu = CTC_BUFSIZE_DEFAULT - LL_HEADER_LENGTH
- 2;
> dev->hard_start_xmit = ctc_tx;
> @@ -2823,7 +2802,7 @@ ctc_init_netdevice(struct net_device * d
> dev->type = ARPHRD_SLIP;
> dev->tx_queue_len = 100;
> dev->flags = IFF_POINTOPOINT | IFF_NOARP;
> - return dev;
> + SET_MODULE_OWNER(dev);
> }
>
>
> @@ -2879,14 +2858,22 @@ ctc_new_device(struct ccwgroup_device *c
> "ccw_device_set_online (cdev[1])
failed with ret = %d\n", ret);
> }
>
> - dev = ctc_init_netdevice(NULL, 1, privptr);
> -
> + dev = alloc_netdev(0, "ctc%d", ctc_init_netdevice);
> if (!dev) {
> ctc_pr_warn("ctc_init_netdevice failed\n");
> goto out;
> }
> + dev->priv = privptr;
>
Why not use standard private data area, rather than allocating
it separately?
--
Stephen Hemminger <shemminger@...ux-foundation.org>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists