lwn.git/drivers/usb/gadget, branch v3.12.5

Merge tag 'fixes-for-v3.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus

2013-10-01T21:22:05+00:00

Felipe writes: usb: fixes for v3.12-rc4 Here are some more fixes to musb's OTG support and a regression caused on latest merge window; pxa25x_udc and gpio-vbus learned to cope with deferred probe; s3c-hsotg got a fix for non-periodic endpoints write size and f_fs got an error handling fix for cases where ffs_do_descs() fail. Signed-of-by: Felipe Balbi

usb: gadget: s3c-hsotg: fix can_write limit for non-periodic endpoints

2013-10-01T14:24:14+00:00

Value of can_write variable in s3c_hsotg_write_fifo function should be limited to 512 only for non-periodic endpoints. There was some discrepancy between comment and code, because comment suggests correct behavior, but in the code limit was applied to periodic endpoints too. So there is additional check causing the limitation concerns only non-periodic endpoints. Signed-off-by: Robert Baldyga Signed-off-by: Kyungmin Park Signed-off-by: Felipe Balbi

usb: gadget: f_fs: fix error handling

2013-10-01T14:04:22+00:00

This patch add missing error check in ffs_func_bind() function, after ffs_do_descs() function call for high speed descriptors. Without this check it's possible that the module will try dereference incorrect pointer. [ balbi@ti.com : removed trailing empty line ] Acked-by: Michal Nazarewicz Signed-off-by: Robert Baldyga Signed-off-by: Felipe Balbi

USB: Fix breakage in ffs_fs_mount()

2013-09-26T23:22:29+00:00

There's a bunch of failure exits in ffs_fs_mount() with seriously broken recovery logics. Most of that appears to stem from misunderstanding of the ->kill_sb() semantics; unlike ->put_super() it is called for *all* superblocks of given type, no matter how (in)complete the setup had been. ->put_super() is called only if ->s_root is not NULL; any failure prior to setting ->s_root will have the call of ->put_super() skipped. ->kill_sb(), OTOH, awaits every superblock that has come from sget(). Current behaviour of ffs_fs_mount(): We have struct ffs_sb_fill_data data on stack there. We do ffs_dev = functionfs_acquire_dev_callback(dev_name); and store that in data.private_data. Then we call mount_nodev(), passing it ffs_sb_fill() as a callback. That will either fail outright, or manage to call ffs_sb_fill(). There we allocate an instance of struct ffs_data, slap the value of ffs_dev (picked from data.private_data) into ffs->private_data and overwrite data.private_data by storing ffs into an overlapping member (data.ffs_data). Then we store ffs into sb->s_fs_info and attempt to set the rest of the things up (root inode, root dentry, then create /ep0 there). Any of those might fail. Should that happen, we get ffs_fs_kill_sb() called before mount_nodev() returns. If mount_nodev() fails for any reason whatsoever, we proceed to functionfs_release_dev_callback(data.ffs_data); That's broken in a lot of ways. Suppose the thing has failed in allocation of e.g. root inode or dentry. We have functionfs_release_dev_callback(ffs); ffs_data_put(ffs); done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by functionfs_release_dev_callback(ffs); from ffs_fs_mount() (via data.ffs_data). Note that the second functionfs_release_dev_callback() has every chance to be done to freed memory. Suppose we fail *before* root inode allocation. What happens then? ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all, or it doesn't have a pointer to ffs stored in sb->s_fs_info). And functionfs_release_dev_callback(data.ffs_data); is called by ffs_fs_mount(), but here we are in nasal daemon country - we are reading from a member of union we'd never stored into. In practice, we'll get what we used to store into the overlapping field, i.e. ffs_dev. And then we get screwed, since we treat it (struct gfs_ffs_obj * in disguise, returned by functionfs_acquire_dev_callback()) as struct ffs_data *, pick what would've been ffs_data ->private_data from it (*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data is much bigger) and poke in whatever it points to. FWIW, there's a minor leak on top of all that in case if ffs_sb_fill() fails on kstrdup() - ffs is obviously forgotten. The thing is, there is no point in playing all those games with union. Just allocate and initialize ffs_data *before* calling mount_nodev() and pass a pointer to it via data.ffs_data. And once it's stored in sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that it doesn't need to kill the sucker manually - from that point on we'll have it done by ->kill_sb(). Signed-off-by: Al Viro Acked-by: Michal Nazarewicz Cc: stable # 3.3+ Signed-off-by: Greg Kroah-Hartman

usb: gadget: pxa25x_udc: fix deferred probe from __init

2013-09-23T19:29:49+00:00

Move probe out of __init section and don't use platform_driver_probe which cannot be used with deferred probing. Since commit e9354576 ("gpiolib: Defer failed gpio requests by default") this driver might return -EPROBE_DEFER if a gpio_request fails. Cc: Eric Miao Cc: Russell King Cc: Haojian Zhuang Cc: Felipe Balbi Signed-off-by: Johan Hovold Signed-off-by: Felipe Balbi

Merge tag 'fixes-for-v3.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus

2013-09-17T20:00:43+00:00

Felipe writes: usb: fixes for v3.12-rc2 Here's first set of fixes for v3.12-rc series, patches have been soaking in linux-usb for a while now. We have the usual sparse and build warnings, a Kconfig fix to a mismerge on dwc3 Kconfig, fix for a possible memory leak in dwc3, s3c-hsotg won't disconnect when bus goes idle, locking fix in mv_u3d_core, endpoint disable fix in f_mass_storage. We also have one device ID added to dwc3's PCI glue layer in order to support Intel's BayTrail devices. Signed-of-by: Felipe Balbi

USB: Faraday fotg210: fix email addresses

2013-09-17T16:36:10+00:00

Update the MODULE_AUTHOR field of the Faraday OTG drivers to reflect current maintainers email address. Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman

usb: s3c-hsotg: do not disconnect gadget when receiving ErlySusp intr

2013-09-17T16:08:46+00:00

DWC2 databook indicates if the core sets "ErlySusp" bit, an idle state has been detected on the USB for 3 ms. This situation can be occurred when waiting a request from user daemon. So, we should keep the connection between udc and gadget even though this interrupt is occurred. Signed-off-by: Chanho Park Signed-off-by: Robert Baldyga Signed-off-by: Kyungmin Park Signed-off-by: Felipe Balbi

usb: s3c-hsotg: fix unregistration function

2013-09-17T16:08:45+00:00

After driver conversion to udc_start/udc_stop infrastructure (commit "usb:hsotg:samsung: Use new udc_start and udc_stop callbacks" f65f0f1098) the gadget unregistration function is almost always called with 'driver' parameter being NULL, what caused that the unregistration code has not been executed at all. This is a leftover from the earlier verison of this function (which used simple start/stop interface), where driver parameter was obligatory. This patch removes the NULL check for the 'driver' pointer and removes all dereferences of it. It also moves disabling voltage regulators out of the atomic context, because handling regulators (which are usually i2c devices) might require sleeping. Signed-off-by: Marek Szyprowski Signed-off-by: Robert Baldyga Signed-off-by: Kyungmin Park Signed-off-by: Felipe Balbi

usb: gadget: f_mass_storage: reset endpoint driver data when disabled

2013-09-17T16:07:14+00:00

Gadgets endpoint driver data is a criteria to judge that whether the endpoints are in use or not. When gadget gets assigned an endpoint from endpoint list, they check its driver data if the driver data is NULL. If the driver data is not NULL then they regard it as in use. Therefore all of gadgets should reset their endpoints driver data to NULL as they are disabled. Otherwise it causes a leak of endpoint resource. Signed-off-by: Peter Oh Signed-off-by: Felipe Balbi