linux-next: manual merge of the usb-gadget tree with the vfs tree

linux-next: manual merge of the usb-gadget tree with the vfs tree

[Stephen Rothwell]

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

Hi Felipe,

Today's linux-next merge of the usb-gadget tree got a conflict in
drivers/usb/gadget/function/f_fs.c between commit 8322215aa91c ("f_fs:
saner API for ffs_sb_create_file()") from the vfs tree and commit
1b0bf88fd8b8 ("usb: gadget: f_fs: virtual endpoint address mapping")
from the usb-gadget tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/usb/gadget/function/f_fs.c
index 4726e278e557,4ad11e03cf54..000000000000
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@@ -1529,11 -1557,13 +1552,14 @@@ static int ffs_epfiles_create(struct ff
  		epfile->ffs = ffs;
  		mutex_init(&epfile->mutex);
  		init_waitqueue_head(&epfile->wait);
- 		sprintf(epfiles->name, "ep%u",  i);
+ 		if (ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
+ 			sprintf(epfiles->name, "ep%02x", ffs->eps_addrmap[i]);
+ 		else
+ 			sprintf(epfiles->name, "ep%u", i);
 -		if (!unlikely(ffs_sb_create_file(ffs->sb, epfiles->name, epfile,
 -						 &ffs_epfile_operations,
 -						 &epfile->dentry))) {
 +		epfile->dentry = ffs_sb_create_file(ffs->sb, epfiles->name,
 +						 epfile,
 +						 &ffs_epfile_operations);
 +		if (unlikely(!epfile->dentry)) {
  			ffs_epfiles_destroy(epfiles, i - 1);
  			return -ENOMEM;
  		}

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

Re: linux-next: manual merge of the usb-gadget tree with the vfs tree

[Robert Baldyga]

On 09/17/2014 08:16 AM, Stephen Rothwell wrote:
> Hi Felipe,
> 
> Today's linux-next merge of the usb-gadget tree got a conflict in
> drivers/usb/gadget/function/f_fs.c between commit 8322215aa91c ("f_fs:
> saner API for ffs_sb_create_file()") from the vfs tree and commit
> 1b0bf88fd8b8 ("usb: gadget: f_fs: virtual endpoint address mapping")
> from the usb-gadget tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 

Looks good for me.

Thanks
Robert Baldyga

Re: linux-next: manual merge of the usb-gadget tree with the vfs tree

[Felipe Balbi]

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

On Wed, Sep 17, 2014 at 04:16:58PM +1000, Stephen Rothwell wrote:
> Hi Felipe,
> 
> Today's linux-next merge of the usb-gadget tree got a conflict in
> drivers/usb/gadget/function/f_fs.c between commit 8322215aa91c ("f_fs:

I can't find this commit on linux-usb. In fact, googling for it the only
reference I find to that commit is this very thread. I would strong
suggest that it be removed from the tree as it, apparently, went in
without any review. Sure, it's a simple change, but it needs to be
reviewed and needs to be sent to proper maintainers.

Unless I'm missing something, of course, but I could not find any other
references to this commit.

Al, was this commit sent to any mailing list ?

cheers

-- 
balbi

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

Re: linux-next: manual merge of the usb-gadget tree with the vfs tree

[Felipe Balbi]

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

Hi,

On Wed, Sep 17, 2014 at 10:34:00AM -0500, Felipe Balbi wrote:
> On Wed, Sep 17, 2014 at 04:16:58PM +1000, Stephen Rothwell wrote:
> > Hi Felipe,
> > 
> > Today's linux-next merge of the usb-gadget tree got a conflict in
> > drivers/usb/gadget/function/f_fs.c between commit 8322215aa91c ("f_fs:
> 
> I can't find this commit on linux-usb. In fact, googling for it the only
> reference I find to that commit is this very thread. I would strong
> suggest that it be removed from the tree as it, apparently, went in
> without any review. Sure, it's a simple change, but it needs to be
> reviewed and needs to be sent to proper maintainers.
> 
> Unless I'm missing something, of course, but I could not find any other
> references to this commit.
> 
> Al, was this commit sent to any mailing list ?

a gentle ping here

-- 
balbi

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

Re: linux-next: manual merge of the usb-gadget tree with the vfs tree

[Al Viro]

On Thu, Sep 18, 2014 at 12:12:26PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Sep 17, 2014 at 10:34:00AM -0500, Felipe Balbi wrote:
> > On Wed, Sep 17, 2014 at 04:16:58PM +1000, Stephen Rothwell wrote:
> > > Hi Felipe,
> > > 
> > > Today's linux-next merge of the usb-gadget tree got a conflict in
> > > drivers/usb/gadget/function/f_fs.c between commit 8322215aa91c ("f_fs:
> > 
> > I can't find this commit on linux-usb. In fact, googling for it the only
> > reference I find to that commit is this very thread. I would strong
> > suggest that it be removed from the tree as it, apparently, went in
> > without any review. Sure, it's a simple change, but it needs to be
> > reviewed and needs to be sent to proper maintainers.
> > 
> > Unless I'm missing something, of course, but I could not find any other
> > references to this commit.
> > 
> > Al, was this commit sent to any mailing list ?
> 
> a gentle ping here

<looks at #for-next>

Oh, bugger...  I see what has happened - there's a local queue with a lot
of pending cleanups; this (and several around it) got into the wrong queue
and leaked into #for-next.  My apologies; I can certainly take this stuff
out.  It is an obvious patch, and the only reason why it's there at all
is that it's a part of preliminary cleanups for sorting the
d_add/d_splice_alias/d_materialise_unique/d_instantiate/d_add_unique
mess out.  That almost certainly will be a part of the next cycle, in
the first place, and this particular commit isn't even a prereq - it's just
something that fell out of grep while sorting out the calling conventions
for those guys (what's locked, what is or isn't hashed, etc.)

So I've no problems whatsoever either with ripping it out of -next and moving
it to the local queue until the next cycle, or throwing it your way and waiting
for it to hit the mainline.  Both f_fs and gadgetfs commits should go your
way, right?  Just tell which way you prefer them handled...  Again, I hadn't
planned to push those; there's no reason not to, but they can certainly sit
around for longer.  Sorry about the mess...

Re: linux-next: manual merge of the usb-gadget tree with the vfs tree

[Felipe Balbi]

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

Hi,

On Thu, Sep 18, 2014 at 07:09:21PM +0100, Al Viro wrote:
> > > > Today's linux-next merge of the usb-gadget tree got a conflict in
> > > > drivers/usb/gadget/function/f_fs.c between commit 8322215aa91c ("f_fs:
> > > 
> > > I can't find this commit on linux-usb. In fact, googling for it the only
> > > reference I find to that commit is this very thread. I would strong
> > > suggest that it be removed from the tree as it, apparently, went in
> > > without any review. Sure, it's a simple change, but it needs to be
> > > reviewed and needs to be sent to proper maintainers.
> > > 
> > > Unless I'm missing something, of course, but I could not find any other
> > > references to this commit.
> > > 
> > > Al, was this commit sent to any mailing list ?
> > 
> > a gentle ping here
> 
> <looks at #for-next>
> 
> Oh, bugger...  I see what has happened - there's a local queue with a lot
> of pending cleanups; this (and several around it) got into the wrong queue
> and leaked into #for-next.  My apologies; I can certainly take this stuff
> out.  It is an obvious patch, and the only reason why it's there at all
> is that it's a part of preliminary cleanups for sorting the
> d_add/d_splice_alias/d_materialise_unique/d_instantiate/d_add_unique
> mess out.  That almost certainly will be a part of the next cycle, in
> the first place, and this particular commit isn't even a prereq - it's just
> something that fell out of grep while sorting out the calling conventions
> for those guys (what's locked, what is or isn't hashed, etc.)
> 
> So I've no problems whatsoever either with ripping it out of -next and moving
> it to the local queue until the next cycle, or throwing it your way and waiting
> for it to hit the mainline.  Both f_fs and gadgetfs commits should go your
> way, right?  Just tell which way you prefer them handled...  Again, I hadn't
> planned to push those; there's no reason not to, but they can certainly sit
> around for longer.  Sorry about the mess...

Hey, no problem. At least now we know it was just a mistake. If you can
just add my Acked-by: Felipe Balbi <balbi@ti.com> to both gadgetfs and
f_fs, I'd be very glad.

Thanks for looking into it.

cheers

-- 
balbi

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