All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: DaeSeok Youn <daeseok.youn@gmail.com>
Cc: Mark Hounschell <markh@compro.net>,
	devel <devel@driverdev.osuosl.org>,
	Lidza Louina <lidza.louina@gmail.com>,
	driverdev-devel@linuxdriverproject.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] staging: dgap: implement error handling in dgap_tty_register()
Date: Sat, 26 Apr 2014 21:48:23 +0300	[thread overview]
Message-ID: <20140426184721.GL26890@mwanda> (raw)
In-Reply-To: <CAHb8M2AgDzTzABys5Ec=tjg4xDaAORjPpVcjXykgWFKPtPnCMQ@mail.gmail.com>

On Sat, Apr 26, 2014 at 11:39:38AM +0900, DaeSeok Youn wrote:
> Hi,
> 
> please check below my comments.
> 
> 2014-04-25 23:41 GMT+09:00 Mark Hounschell <markh@compro.net>:
> > On 04/25/2014 08:59 AM, Dan Carpenter wrote:
> >> On Fri, Apr 25, 2014 at 08:29:41AM -0400, Mark Hounschell wrote:
> >>> On 04/25/2014 07:02 AM, DaeSeok Youn wrote:
> >>>> Hi, Dan.
> >>>>
> >>>> 2014-04-25 18:26 GMT+09:00 Dan Carpenter <dan.carpenter@oracle.com>:
> >>>>> Mark, maybe you should add yourself to the MAINTAINERS entry for this
> >>>>> driver?
> >>>>>
> >>>
> >>> I'll look into this. I am clueless on what that would actually mean.
> >>>
> >>
> >> Just add your name with Lidza in the MAINTAINERS file so that people
> >> will CC you on all the patches.
> >>
> >> DIGI EPCA PCI PRODUCTS
> >> M:      Lidza Louina <lidza.louina@gmail.com>
> >> L:      driverdev-devel@linuxdriverproject.org
> >> S:      Maintained
> >> F:      drivers/staging/dgap/
> >>
> >> You don't have to do it if you don't want to, but you seem to be working
> >> on this driver and I'm going to refer questions to you either way.  :P
> >>
> >>>>> On Fri, Apr 25, 2014 at 04:04:59PM +0900, Daeseok Youn wrote:
> >>>>>> @@ -1263,7 +1277,8 @@ static int dgap_tty_register(struct board_t *brd)
> >>>>>>               /* Register tty devices */
> >>>>>>               rc = tty_register_driver(brd->SerialDriver);
> >>>>>>               if (rc < 0)
> >>>>>> -                     return rc;
> >>>>>> +                     goto free_print_ttys;
> >>>>>> +
> >>>>>>               brd->dgap_Major_Serial_Registered = TRUE;
> >>>>>>               dgap_BoardsByMajor[brd->SerialDriver->major] = brd;
> >>>>>>               brd->dgap_Serial_Major = brd->SerialDriver->major;
> >>>>>> @@ -1273,13 +1288,29 @@ static int dgap_tty_register(struct board_t *brd)
> >>>>>>               /* Register Transparent Print devices */
> >>>>>>               rc = tty_register_driver(brd->PrintDriver);
> >>>>>>               if (rc < 0)
> >>>>>> -                     return rc;
> >>>>>> +                     goto unregister_serial_drv;
> >>>>>> +
> >>>>>>               brd->dgap_Major_TransparentPrint_Registered = TRUE;
> >>>>>>               dgap_BoardsByMajor[brd->PrintDriver->major] = brd;
> >>>>>>               brd->dgap_TransparentPrint_Major = brd->PrintDriver->major;
> >>>>>>       }
> >>>>>>
> >>>>>>       return rc;
> >>>>>> +
> >>>>>> +unregister_serial_drv:
> >>>>>> +     tty_unregister_driver(brd->SerialDriver);
> >>>>>
> >>>>> We only register the ->SerialDriver if someone else hasn't registered it
> >>>>> first?  So this should be:
> >>>>>
> >>>>>         if (we_were_the_ones_who_registered_the_serial_driver)
> >>>>>                 tty_unregister_driver(brd->SerialDriver);
> >>>>>
> >>>>> I haven't followed looked at this.  Who else is registering the serial
> >>>>> driver?  You have looked at this, what do you think?  Or Mark.
> >>>>
> >>>
> >>> registering the brd->XxxxxDriver is only done when a board is detected
> >>> and only during the firmware_load process. If we fail to
> >>> tty_register_driver do we _need_ to tty_unregister_driver? Isn't that
> >>> like freeing after an alloc failure?
> >>
> >> The allocation is conditional so the free should be conditional.  If we
> >> didn't allocate it, then we shouldn't free it.
> >>
> >> It wouldn't have even been a question except I'm not sure the allocation
> >> is *really* conditional because brd->dgap_Major_Serial_Registered might
> >> always be "false" like you guys seem to be saying.
> >>
> >>>
> >>>> I think brd struct is from dgap_Board array as global static variable
> >>>> when this function is
> >>>> called. So brd->dgap_Major_Serial_Registered is always "false".
> >>>> If dgap_NumBoards is less than MAXBOARDS, brd->SerialDriver should be
> >>>> registered.
> >>>>
> >>>> I'm not sure..
> >>>>
> >>>
> >>> I don't see any check for (dgap_NumBoards <  MAXBOARDS), which I think I
> >>> probably should, but I do see we are calling dgap_tty_register, which
> >>> can fail, without actually checking the return value. Also, yes,
> >>> dgap_Major_Xxxx_Registered seems to be always "false" until registered,
> >>> and it looks like dgap_Major_Xxxxx_Registered flags could be removed
> >>> because the only places we can unregister is at module_cleanup or
> >>> "after" it is already registered.
> >>>
> >>> What is the driver _supposed_ to do if we fail something on the second
> >>> or later board? Is the driver supposed to cleanup and exit or are we
> >>> supposed to stay loaded for the board/boards that are usable?
> >>
> >> Stay loaded.
> >>
> >
> > Then these tests on brd->dgap_Major_Serial_Registered need to stay in
> > there. If I have 3 boards and the second fails in some way, if I rmmod
> > the driver they will protect from unregistering a never registered one.
> > At least in the unregister code path. There is probably no need for them
> > in the register code path. I'll work up a patch for this.
> 
> Should I update my patch?
> 
> I think "if (!brd->dgap_Major_XXX_Registered)" line can be removed in this
> function, because if tty_register_driver() is failed just set "false"
> to "dgap_Major_XXX_Registered".

Mark sent a patch to remove the check.  Could you redo your patch based
on his?

regards,
dan carpenter


  reply	other threads:[~2014-04-26 18:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25  7:04 [PATCH] staging: dgap: implement error handling in dgap_tty_register() Daeseok Youn
2014-04-25  9:26 ` Dan Carpenter
2014-04-25 11:02   ` DaeSeok Youn
     [not found]   ` <875455568.760649.1398423734122.JavaMail.root@mx2.compro.net>
2014-04-25 12:29     ` Mark Hounschell
2014-04-25 12:59       ` Dan Carpenter
     [not found]       ` <1016949935.761818.1398430870736.JavaMail.root@mx2.compro.net>
2014-04-25 14:41         ` Mark Hounschell
2014-04-26  2:39           ` DaeSeok Youn
2014-04-26 18:48             ` Dan Carpenter [this message]
2014-04-27 23:21               ` DaeSeok Youn
2014-05-16  9:40                 ` DaeSeok Youn
2014-05-16  9:52                   ` Dan Carpenter
2014-05-16 10:31                     ` DaeSeok Youn
2014-05-16 15:01                     ` Greg KH
2014-05-16 23:09 ` Greg KH
2014-05-17 15:22   ` DaeSeok Youn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140426184721.GL26890@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=daeseok.youn@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=driverdev-devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lidza.louina@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markh@compro.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.