All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Robert Baldyga <r.baldyga@samsung.com>
Cc: <balbi@ti.com>, <gregkh@linuxfoundation.org>,
	<linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<mina86@mina86.com>, <m.szyprowski@samsung.com>,
	<k.opasiak@samsung.com>, <stern@rowland.harvard.edu>
Subject: Re: [PATCH v5] usb: gadget: f_fs: add "no_disconnect" mode
Date: Tue, 13 Jan 2015 10:32:16 -0600	[thread overview]
Message-ID: <20150113163216.GH16533@saruman> (raw)
In-Reply-To: <1418892910-23890-1-git-send-email-r.baldyga@samsung.com>

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

Hi,

On Thu, Dec 18, 2014 at 09:55:10AM +0100, Robert Baldyga wrote:
> Since we can compose gadgets from many functions, there is the problem
> related to gadget breakage while FunctionFS daemon being closed. FFS
> function is userspace code so there is no way to know when it will close
> files (it doesn't matter what is the reason of this situation, it can
> be daemon logic, program breakage, process kill or any other). So when
> we have another function in gadget which, for example, sends some amount
> of data, does some software update or implements some real-time functionality,
> we may want to keep the gadget connected despite FFS function is no longer
> functional.
> 
> We can't just remove one of functions from gadget since it has been
> enumerated, so the only way to keep entire gadget working is to make
> broken FFS function deactivated but still visible to host. For this
> purpose this patch introduces "no_disconnect" mode. It can be enabled
> by setting mount option "no_disconnect=1", and results with defering
> function disconnect to the moment of reopen ep0 file or filesystem
> unmount. After closing all endpoint files, FunctionFS is set to state
> FFS_DEACTIVATED.
> 
> When ffs->state == FFS_DEACTIVATED:
> - function is still bound and visible to host,
> - setup requests are automatically stalled,
> - transfers on other endpoints are refused,
> - epfiles, except ep0, are deleted from the filesystem,
> - opening ep0 causes the function to be closed, and then FunctionFS
>   is ready for descriptors and string write,
> - altsetting change causes the function to be closed - we want to keep
>   function alive until another functions are potentialy used, altsetting
>   change means that another configuration is being selected or USB cable
>   was unplugged, which indicates that we don't need to stay longer in
>   FFS_DEACTIVATED state
> - unmounting of the FunctionFS instance causes the function to be closed.
> 
> Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
> 
> Changelog:
> 
> v5:
> - close function on altsetting change
> 
> v4: https://lkml.org/lkml/2014/10/9/224
> - use ffs_data_reset() instead of ffs_data_clear() to reset ffs data
>   properly after ffs->ref refcount reach 0 (or under in no_disconnect
>   mode) in ffs_data_put() function
> 
> v3: https://lkml.org/lkml/2014/10/9/170
> - change option name to more descriptive and less scary,
> - fix cleaning up on unmount (call ffs_data_closed() in ffs_fs_kill_sb(),
>   and ffs_data_clear() in ffs_data_closed() if ffs->opened is negative).
> 
> v2: https://lkml.org/lkml/2014/10/7/109
> - delete epfiles, excepting ep0, when FFS is in "zombie" mode,
> - add description of FFS_ZOMBIE state,
> - minor cleanups.
> 
> v1: https://lkml.org/lkml/2014/10/6/128

This changelog should be after the tearline, I've manually editted it
and also applied the small modification sugested by Michal. It should
show up on my testing/next soonish.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      parent reply	other threads:[~2015-01-13 16:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18  8:55 [PATCH v5] usb: gadget: f_fs: add "no_disconnect" mode Robert Baldyga
2014-12-23 18:48 ` Felipe Balbi
2014-12-23 20:47   ` David Cohen
2014-12-23 23:51     ` Felipe Balbi
2014-12-24 14:32 ` Michal Nazarewicz
2015-01-13 16:32 ` Felipe Balbi [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=20150113163216.GH16533@saruman \
    --to=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=m.szyprowski@samsung.com \
    --cc=mina86@mina86.com \
    --cc=r.baldyga@samsung.com \
    --cc=stern@rowland.harvard.edu \
    /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.