All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Robert Baldyga <r.baldyga@samsung.com>, balbi@ti.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, andrzej.p@samsung.com,
	k.opasiak@samsung.com, Robert Baldyga <r.baldyga@samsung.com>
Subject: Re: [PATCH v2] usb: gadget: f_fs: add "zombie" mode
Date: Tue, 07 Oct 2014 12:07:41 +0200	[thread overview]
Message-ID: <xa1t61fwyyz6.fsf@mina86.com> (raw)
In-Reply-To: <1412668742-14831-1-git-send-email-r.baldyga@samsung.com>

On Tue, Oct 07 2014, Robert Baldyga <r.baldyga@samsung.com> wrote:
> @@ -1411,8 +1425,17 @@ static void ffs_data_closed(struct ffs_data *ffs)
>  	ENTER();
>  
>  	if (atomic_dec_and_test(&ffs->opened)) {
> -		ffs->state = FFS_CLOSING;
> -		ffs_data_reset(ffs);
> +		if (ffs->zombie_mode) {
> +			ffs->state = FFS_ZOMBIE;
> +			if (ffs->epfiles)
> +				ffs_epfiles_delete(ffs->epfiles,
> +						   ffs->eps_count);

This looks suspicious.  Why isn't it:

+			if (ffs->epfiles) {
+				ffs_epfiles_destroy(ffs->epfiles,
+						   ffs->eps_count);
+				ffs->epfiles = NULL;
+			}

If ffs->epfiles is not NULLed, call to ffs_data_reset in ffs_data_open
will call ffs_epfiles_destroy which we don't want, do we?

> +			if (ffs->setup_state == FFS_SETUP_PENDING)
> +				__ffs_ep0_stall(ffs);
> +		} else {
> +			ffs->state = FFS_CLOSING;
> +			ffs_data_reset(ffs);
> +		}
>  	}
>  
>  	ffs_data_put(ffs);

> @@ -93,6 +93,26 @@ enum ffs_state {
>  	FFS_ACTIVE,
>  
>  	/*
> +	 * Function is visible to host, but it's not functional. All
> +	 * setup requests are stalled and another transfers are refused.

“and transfers on other endpoints are refused.”

> +	 * All epfiles, excepting ep0, are deleted so there is no way

s/excepting/except/

> +	 * to perform any operations on them.
> +	 *
> +	 * This state is set after closing all functionfs files, when
> +	 * mount parameter "zombie=1" has been set. Function will remain
> +	 * in zombie state until filesystem will be umounted or ep0 will

s/will be umounted/is unmounted/
s/ep0 will be/ep0 is/

> +	 * be opened again. In the second case functionfs state will be
> +	 * reseted, and it will be ready for descriptors and strings

s/reseted/reset/

> +	 * writing.
> +	 *
> +	 * This is useful only when functionfs is composed to gadget
> +	 * with another function which can perform some critical
> +	 * operations, and it's strongly desired to have this operations
> +	 * completed, even after functionfs files closure.
> +	 */
> +	FFS_ZOMBIE,
> +
> +	/*
>  	 * All endpoints have been closed.  This state is also set if
>  	 * we encounter an unrecoverable error.  The only
>  	 * unrecoverable error is situation when after reading strings

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

  reply	other threads:[~2014-10-07 10:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07  7:59 [PATCH v2] usb: gadget: f_fs: add "zombie" mode Robert Baldyga
2014-10-07 10:07 ` Michal Nazarewicz [this message]
2014-10-07 10:29   ` Robert Baldyga

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=xa1t61fwyyz6.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=andrzej.p@samsung.com \
    --cc=balbi@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=k.opasiak@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=r.baldyga@samsung.com \
    /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.