public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox