Re: [PATCH] staging: r8188eu: handle rtw_init_netdev_name() failure appropriately

[Vihas Mak]

>> rtw_init_netdev_name() has an error message in case of allocation
>> failure. It looks like it's better to handle the error normally and pass
>> it to caller
By that you mean:
    goto handle_dualmac;
and freeing the adapter.
right?
FYI, if the allocation fails then it assigns the name using default
format i.e. "eth%d".

On Mon, Jan 17, 2022 at 3:17 AM Pavel Skripkin <paskripkin@xxxxxxxxx> wrote:
>
> Hi Vihas,
>
> On 1/16/22 22:26, Vihas Mak wrote:
> > rtw_init_netdev_name() calls dev_alloc_name() which allocates the name
> > for the device as per the given name format.
> > It returns a negative err code if the format is invalid. Currently the
> > name format is specified by the module parameter "ifname".
> > Warn the user if "ifname" is invalid.
> >
> > Signed-off-by: Vihas Mak <makvihas@xxxxxxxxx>
> > ---
> >   drivers/staging/r8188eu/os_dep/usb_intf.c | 5 ++++-
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/r8188eu/os_dep/usb_intf.c b/drivers/staging/r8188eu/os_dep/usb_intf.c
> > index 91792dfd3..875815b5e 100644
> > --- a/drivers/staging/r8188eu/os_dep/usb_intf.c
> > +++ b/drivers/staging/r8188eu/os_dep/usb_intf.c
> > @@ -399,7 +399,10 @@ static struct adapter *rtw_usb_if1_init(struct dvobj_priv *dvobj,
> >                       DBG_88E("can't get autopm:\n");
> >
> >       /*  alloc dev name after read efuse. */
> > -     rtw_init_netdev_name(pnetdev, padapter->registrypriv.ifname);
> > +     if (rtw_init_netdev_name(pnetdev, padapter->registrypriv.ifname) < 0) {
> > +             DBG_88E("rtw_init_netdev_name failed, ifname:%s\n",
> > +                     padapter->registrypriv.ifname);
> > +     }
> >       rtw_macaddr_cfg(padapter->eeprompriv.mac_addr);
> >       rtw_init_wifidirect_addrs(padapter, padapter->eeprompriv.mac_addr,
> >                                 padapter->eeprompriv.mac_addr);
>
> rtw_init_netdev_name() has an error message in case of allocation
> failure. It looks like it's better to handle the error normally and pass
> it to caller
>
>
>
>
> With regards,
> Pavel Skripkin



-- 
Thanks,
Vihas