On Thu, May 29, 2014 at 09:40:39AM +0300, Dan Carpenter wrote:
> On Thu, May 29, 2014 at 09:17:09AM +0900, DaeSeok Youn wrote:
> > Hi, Dan.
> >
> > 2014-05-28 19:11 GMT+09:00 Dan Carpenter :
> > > On Wed, May 28, 2014 at 06:29:38PM +0900, DaeSeok Youn wrote:
> > >> > In your patch it has:
> > >> >
On Thu, May 29, 2014 at 09:17:09AM +0900, DaeSeok Youn wrote:
> Hi, Dan.
>
> 2014-05-28 19:11 GMT+09:00 Dan Carpenter :
> > On Wed, May 28, 2014 at 06:29:38PM +0900, DaeSeok Youn wrote:
> >> > In your patch it has:
> >> > + dgap_tty_uninit(brd, false);
> >> >
> >> > But it should only be "fa
Hi, Dan.
2014-05-28 19:11 GMT+09:00 Dan Carpenter :
> On Wed, May 28, 2014 at 06:29:38PM +0900, DaeSeok Youn wrote:
>> > In your patch it has:
>> > + dgap_tty_uninit(brd, false);
>> >
>> > But it should only be "false" if dgap_tty_init() failed. If
>> > dgap_tty_register_ports() fails then
On Wed, May 28, 2014 at 10:14:03AM -0400, Mark Hounschell wrote:
> Is that TODO-list going to be commited?
The TODO-list is a new thing. People are always complaining that there
isn't a TODO-list with task for people to do. Now I can just search my
inbox and generate one automatically. Fancy, h
On 05/28/2014 06:11 AM, Dan Carpenter wrote:
> On Wed, May 28, 2014 at 06:29:38PM +0900, DaeSeok Youn wrote:
>>> In your patch it has:
>>> + dgap_tty_uninit(brd, false);
>>>
>>> But it should only be "false" if dgap_tty_init() failed. If
>>> dgap_tty_register_ports() fails then it should be
On Wed, May 28, 2014 at 06:29:38PM +0900, DaeSeok Youn wrote:
> > In your patch it has:
> > + dgap_tty_uninit(brd, false);
> >
> > But it should only be "false" if dgap_tty_init() failed. If
> > dgap_tty_register_ports() fails then it should be "true". Another
> Yes, you're right. There wer
Hi, Dan
Please look at below my line comment.
2014-05-28 16:02 GMT+09:00 Dan Carpenter :
> We are talking about different things I think. What I'm saying is that
> there is the normal way to do error handling in the kernel. That's with
> a series of labels like this:
>
> ...
> r
We are talking about different things I think. What I'm saying is that
there is the normal way to do error handling in the kernel. That's with
a series of labels like this:
...
return 0;
err_free_ttys:
free_ttys();
err_free_channels:
free_channels();
err_free_brd
Hi, Dan.
2014-05-27 19:20 GMT+09:00 Dan Carpenter :
> The "brd->nasync = 0;" was wrong, yes, but my main complaint was that
> you are writing complicated error handling. This v2 patch makes the
> error handling even more complicated. If dgap_tty_init() fails it
> should free the things it alloca
The "brd->nasync = 0;" was wrong, yes, but my main complaint was that
you are writing complicated error handling. This v2 patch makes the
error handling even more complicated. If dgap_tty_init() fails it
should free the things it allocates itself, instead of the caller
handling errors for it.
It
When dgap_tty_init() and dgap_tty_register_ports() are failed,
these are needed to free some memory properly.
It can be handled by calling dgap_tty_uninit() and dgap_cleanup_board().
But tty's ports are not registered yet when these function are failed,
so it need to switch with boolean value whet
11 matches
Mail list logo