From: Robert Baldyga <r.baldyga@samsung.com>
To: Michal Nazarewicz <mina86@mina86.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
Subject: Re: [PATCH v2] usb: gadget: f_fs: add "zombie" mode
Date: Tue, 07 Oct 2014 12:29:55 +0200 [thread overview]
Message-ID: <5433C0A3.1020302@samsung.com> (raw)
In-Reply-To: <xa1t61fwyyz6.fsf@mina86.com>
On 10/07/2014 12:07 PM, Michal Nazarewicz wrote:
> 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?
>
We do. When epfile->dentry == NULL, ffs_epfiles_destroy() will do only
kfree(epfiles). We want to do it.
We don't want to have ffs->epfiles being equal NULL before calling
ffs_func_eps_disable(), which iterates on this table.
Hmm, we could also change ffs_func_eps_disable() to not touch
ffs->epfiles if it's NULL. It seems to be better solution.
>> + 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
>
Thanks,
Robert Baldyga
prev parent reply other threads:[~2014-10-07 10:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 7:59 Robert Baldyga
2014-10-07 10:07 ` Michal Nazarewicz
2014-10-07 10:29 ` Robert Baldyga [this message]
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=5433C0A3.1020302@samsung.com \
--to=r.baldyga@samsung.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=mina86@mina86.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome