[PATCH V2 2/2] usb: gadget: storage: Remove reference counting

[Jaejoong Kim]

The kref used to be needed because sharing of fsg_common among multiple USB
function instances was handled by fsg. Now this is managed by configfs, we
don't need it anymore. So let's eliminate kref from this driver.

Signed-off-by: Jaejoong Kim 
---
Changes in V2:
  - Rewrite commit title & message.
  - Remove kref instead of removing unused kref EXPORT_SYMBOL (Alan and Michal)

V1 patches
  https://patchwork.kernel.org/patch/10463709/
  https://patchwork.kernel.org/patch/10463713/

 drivers/usb/gadget/function/f_mass_storage.c | 27 +--
 drivers/usb/gadget/function/f_mass_storage.h |  4 
 2 files changed, 5 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 1b580eb..ca8a4b5 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -206,7 +206,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -312,8 +311,6 @@ struct fsg_common {
void*private_data;
 
char inquiry_string[INQUIRY_STRING_LEN];
-
-   struct kref ref;
 };
 
 struct fsg_dev {
@@ -2551,25 +2548,11 @@ static DEVICE_ATTR(file, 0, file_show, file_store);
 
 /** FSG COMMON **/
 
-static void fsg_common_release(struct kref *ref);
-
 static void fsg_lun_release(struct device *dev)
 {
/* Nothing needs to be done */
 }
 
-void fsg_common_get(struct fsg_common *common)
-{
-   kref_get(>ref);
-}
-EXPORT_SYMBOL_GPL(fsg_common_get);
-
-void fsg_common_put(struct fsg_common *common)
-{
-   kref_put(>ref, fsg_common_release);
-}
-EXPORT_SYMBOL_GPL(fsg_common_put);
-
 static struct fsg_common *fsg_common_setup(struct fsg_common *common)
 {
if (!common) {
@@ -2582,7 +2565,6 @@ static struct fsg_common *fsg_common_setup(struct 
fsg_common *common)
}
init_rwsem(>filesem);
spin_lock_init(>lock);
-   kref_init(>ref);
init_completion(>thread_notifier);
init_waitqueue_head(>io_wait);
init_waitqueue_head(>fsg_wait);
@@ -2870,9 +2852,8 @@ void fsg_common_set_inquiry_string(struct fsg_common 
*common, const char *vn,
 }
 EXPORT_SYMBOL_GPL(fsg_common_set_inquiry_string);
 
-static void fsg_common_release(struct kref *ref)
+static void fsg_common_release(struct fsg_common *common)
 {
-   struct fsg_common *common = container_of(ref, struct fsg_common, ref);
int i;
 
/* If the thread isn't already dead, tell it to exit now */
@@ -3346,7 +3327,7 @@ static void fsg_free_inst(struct usb_function_instance 
*fi)
struct fsg_opts *opts;
 
opts = fsg_opts_from_func_inst(fi);
-   fsg_common_put(opts->common);
+   fsg_common_release(opts->common);
kfree(opts);
 }
 
@@ -3370,7 +3351,7 @@ static struct usb_function_instance *fsg_alloc_inst(void)
rc = fsg_common_set_num_buffers(opts->common,
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS);
if (rc)
-   goto release_opts;
+   goto release_common;
 
pr_info(FSG_DRIVER_DESC ", version: " FSG_DRIVER_VERSION "\n");
 
@@ -3393,6 +3374,8 @@ static struct usb_function_instance *fsg_alloc_inst(void)
 
 release_buffers:
fsg_common_free_buffers(opts->common);
+release_common:
+   kfree(opts->common);
 release_opts:
kfree(opts);
return ERR_PTR(rc);
diff --git a/drivers/usb/gadget/function/f_mass_storage.h 
b/drivers/usb/gadget/function/f_mass_storage.h
index 58857fc..3b8c4ce 100644
--- a/drivers/usb/gadget/function/f_mass_storage.h
+++ b/drivers/usb/gadget/function/f_mass_storage.h
@@ -115,10 +115,6 @@ fsg_opts_from_func_inst(const struct usb_function_instance 
*fi)
return container_of(fi, struct fsg_opts, func_inst);
 }
 
-void fsg_common_get(struct fsg_common *common);
-
-void fsg_common_put(struct fsg_common *common);
-
 void fsg_common_set_sysfs(struct fsg_common *common, bool sysfs);
 
 int fsg_common_set_num_buffers(struct fsg_common *common, unsigned int n);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 1/2] usb: gadget: storage: Add error handling for no memory

[Jaejoong Kim]

fsg_common_set_num_buffers() may fail due to ENOMEM. So add
error handling for fail case.

Acked-by: Alan Stern 
Acked-by: Michal Nazarewicz 
Signed-off-by: Jaejoong Kim 
---
Changes in V2:
  Add Acked-by

 drivers/usb/gadget/function/f_mass_storage.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index acecd13..1b580eb 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3308,7 +3308,9 @@ static ssize_t fsg_opts_num_buffers_store(struct 
config_item *item,
if (ret)
goto end;
 
-   fsg_common_set_num_buffers(opts->common, num);
+   ret = fsg_common_set_num_buffers(opts->common, num);
+   if (ret)
+   goto end;
ret = len;
 
 end:
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 0/2] usb: gadget: storage: remove kref and add error handling

[Jaejoong Kim]

Hi

This series remove the reference counting and add error handling.

Changes in V2:
  - patch #1. Add Ack-by
  - patch #2.
Remove kref suggested by Alan and Michal
Update commit message.

Jaejoong Kim (2):
  usb: gadget: storage: Add error handling for no memory
  usb: gadget: storage: Remove reference counting

 drivers/usb/gadget/function/f_mass_storage.c | 31 +++-
 drivers/usb/gadget/function/f_mass_storage.h |  4 
 2 files changed, 8 insertions(+), 27 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dwc2 (on Meson8b) doesn't detect "hot-plugged" USB devices

[Martin Blumenstingl]

Hello Minas,

On Thu, May 10, 2018 at 11:44 AM Martin Blumenstingl
 wrote:
>
> Hello Minas,
>
> On Mon, May 7, 2018 at 3:27 PM, Minas Harutyunyan
>  wrote:
> > Hi Martin,
> >
> > On 5/7/2018 12:28 AM, Martin Blumenstingl wrote:
> >> Hello,
> >>
> >> I was a bit surprised to see that hot-plugging USB devices on Amlogic
> >> Meson8b (for example: Odroid-C1) is broken.
> >> to be fair: I *think* it worked before, but I cannot guarantee it nor
> >> can I say when it broke
> >>
> >> all examples below are from an Odroid-C1 board with Amlogic Meson8b (S805) 
> >> SoC.
> >> this connects a (fixed, soldered down) 4-port USB hub to the dwc2
> >> controller (which is in "host" mode)
> >>
> >> during boot I see:
> >> [1.651687] dwc2 c90c.usb: c90c.usb supply vusb_d not
> >> found, using dummy regulator
> >> [1.654434] dwc2 c90c.usb: c90c.usb supply vusb_a not
> >> found, using dummy regulator
> >> [1.732374] dwc2 c90c.usb: dwc2_check_params: Invalid parameter 
> >> lpm=1
> >> [1.733526] dwc2 c90c.usb: dwc2_check_params: Invalid parameter
> >> lpm_clock_gating=1
> >> [1.741427] dwc2 c90c.usb: dwc2_check_params: Invalid parameter 
> >> besl=1
> >> [1.748305] dwc2 c90c.usb: dwc2_check_params: Invalid parameter
> >> hird_threshold_en=1
> >> [1.756491] dwc2 c90c.usb: DWC OTG Controller
> >> [1.760993] dwc2 c90c.usb: new USB bus registered, assigned bus 
> >> number 1
> >> [1.768046] dwc2 c90c.usb: irq 24, io mem 0xc90c
> >> [1.773947] hub 1-0:1.0: USB hub found
> >> [1.777063] hub 1-0:1.0: 1 port detected
> >> ...
> >> [2.212432] usb 1-1: new high-speed USB device number 2 using dwc2
> >> [2.464742] hub 1-1:1.0: USB hub found
> >> [2.465118] hub 1-1:1.0: 4 ports detected
> >>
> >> if a USB device is plugged into one of the four USB ports during boot
> >> then it is detected automatically.
> >> if I plug in devices later they are not detected automatically (I have
> >> to run "lsusb -v" due to some reason, then hot-plugged devices are
> >> being detected)
> >> un-plugging USB devices is recognized instantly (no "lsusb" trickery
> >> is required)
> >>
> >> is this a known issue? how can I help debugging?
> >> any help is appreciated!
> >>
> >> below is the output of all dwc2 debugfs files.
> >>
> >>
> >> Regards
> >> Martin
> >>
> >>
> >> [rootodroidc1 c90c.usb]# cat dr_mode
> >> host
> >> [rootodroidc1 c90c.usb]# cat fifo
> >> Non-periodic FIFOs:
> >> RXFIFO: Size 0
> >> NPTXFIFO: Size 0, Start 0x
> >>
> >> Periodic TXFIFOs:
> >> [rootodroidc1 c90c.usb]# cat hw_params
> >> op_mode   : 5
> >> arch  : 2
> >> dma_desc_enable   : 1
> >> enable_dynamic_fifo   : 1
> >> en_multiple_tx_fifo   : 0
> >> rx_fifo_size  : 2048
> >> host_nperio_tx_fifo_size  : 2048
> >> dev_nperio_tx_fifo_size   : 0
> >> host_perio_tx_fifo_size   : 2048
> >> nperio_tx_q_depth : 4
> >> host_perio_tx_q_depth : 4
> >> dev_token_q_depth : 8
> >> max_transfer_size : 524287
> >> max_packet_count  : 1023
> >> host_channels : 16
> >> hs_phy_type   : 1
> >> fs_phy_type   : 0
> >> i2c_enable: 0
> >> num_dev_ep: 2
> >> num_dev_perio_in_ep   : 0
> >> total_fifo_size   : 1984
> >> power_optimized   : 1
> >> utmi_phy_data_width   : 1
> >> snpsid: 0x4f54310a
> >> dev_ep_dirs   : 0x0
> >> [rootodroidc1 c90c.usb]# cat params
> >> otg_cap   : 2
> >> dma_desc_enable   : 0
> >> dma_desc_fs_enable: 0
> >> speed : 0
> >> enable_dynamic_fifo   : 1
> >> en_multiple_tx_fifo   : 0
> >> host_rx_fifo_size : 512
> >> host_nperio_tx_fifo_size  : 500
> >> host_perio_tx_fifo_size   : 500
> >> max_transfer_size : 524287
> >> max_packet_count  : 1023
> >> host_channels : 16
> >> phy_type  : 1
> >> phy_utmi_width: 16
> >> phy_ulpi_ddr  : 0
> >> phy_ulpi_ext_vbus : 0
> >> i2c_enable: 0
> >> ulpi_fs_ls: 0
> >> host_support_fs_ls_low_power  : 0
> >> host_ls_low_power_phy_clk : 0
> >> ts_dline  : 0
> >> reload_ctl: 1
> >> ahbcfg: 0xa
> >> uframe_sched  : 0
> >> external_id_pin_ctl   : 0
> >> power_down: 1
> >> lpm   : 0
> >> lpm_clock_gating  : 0
> >> besl  : 0
> >> hird_threshold_en : 0
> >> hird_threshold: 4
> >> host_dma  : 1
> >> g_dma : 0
> >> g_dma_desc   

[RFT] Remove USB bus reset delay from OHCI handover code

[Alan Stern]

I no longer have suitable hardware for testing this patch.  If anyone 
with an OHCI host controller could try it out, I would like to hear if 
it causes any problems.

Thank you all.

Alan Stern



Index: usb-4.x/drivers/usb/host/pci-quirks.c
===
--- usb-4.x.orig/drivers/usb/host/pci-quirks.c
+++ usb-4.x/drivers/usb/host/pci-quirks.c
@@ -783,15 +783,9 @@ static void quirk_usb_handoff_ohci(struc
/* disable interrupts */
writel((u32) ~0, base + OHCI_INTRDISABLE);
 
-   /* Reset the USB bus, if the controller isn't already in RESET */
-   if (control & OHCI_HCFS) {
-   /* Go into RESET, preserving RWC (and possibly IR) */
-   writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
-   readl(base + OHCI_CONTROL);
-
-   /* drive bus reset for at least 50 ms (7.1.7.5) */
-   msleep(50);
-   }
+   /* Go into the USB_RESET state, preserving RWC (and possibly IR) */
+   writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
+   readl(base + OHCI_CONTROL);
 
/* software reset of the controller, preserving HcFmInterval */
if (!no_fminterval)

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] usb: gadget: configfs: Create control_config group

[Jerry Zhang]

Control_config is a group under gadget that acts
as a normal config group, except it does not
appear in cdev->configs.

Functions that have exactly zero descriptors can
be linked into control_config. These functions
are bound and unbound with the rest of the gadget,
but are never enabled. Also, functions with zero
descriptors cannot be used in real configs.

Create configfs_setup(), which will first attempt
composite setup. If that fails, it will go through
functions in control_config and use req_match to
find and deliver the request to a function that can
handle it.

This allows the user to create a functionfs instance
dedicated to handling non-standard control requests
no matter what functions or configurations are
currently active.

Signed-off-by: Jerry Zhang 
---
 drivers/usb/gadget/configfs.c | 114 --
 1 file changed, 96 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index efba66ca0719..ed3d675ee7bb 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -44,12 +44,22 @@ int check_user_usb_string(const char *name,
 
 static const struct usb_descriptor_header *otg_desc[2];
 
+struct config_usb_cfg {
+   struct config_group group;
+   struct config_group strings_group;
+   struct list_head string_list;
+   struct usb_configuration c;
+   struct list_head func_list;
+   struct usb_gadget_strings *gstrings[MAX_USB_STRING_LANGS + 1];
+};
+
 struct gadget_info {
struct config_group group;
struct config_group functions_group;
struct config_group configs_group;
struct config_group strings_group;
struct config_group os_desc_group;
+   struct config_usb_cfg control_config;
 
struct mutex lock;
struct usb_gadget_strings *gstrings[MAX_USB_STRING_LANGS + 1];
@@ -68,15 +78,6 @@ static inline struct gadget_info *to_gadget_info(struct 
config_item *item)
 return container_of(to_config_group(item), struct gadget_info, group);
 }
 
-struct config_usb_cfg {
-   struct config_group group;
-   struct config_group strings_group;
-   struct list_head string_list;
-   struct usb_configuration c;
-   struct list_head func_list;
-   struct usb_gadget_strings *gstrings[MAX_USB_STRING_LANGS + 1];
-};
-
 static inline struct config_usb_cfg *to_config_usb_cfg(struct config_item 
*item)
 {
return container_of(to_config_group(item), struct config_usb_cfg,
@@ -512,6 +513,16 @@ static const struct config_item_type gadget_config_type = {
.ct_owner   = THIS_MODULE,
 };
 
+static struct configfs_item_operations control_config_item_ops = {
+   .allow_link = config_usb_cfg_link,
+   .drop_link  = config_usb_cfg_unlink,
+};
+
+static const struct config_item_type control_config_type = {
+   .ct_item_ops= _config_item_ops,
+   .ct_owner   = THIS_MODULE,
+};
+
 static const struct config_item_type gadget_root_type = {
.ct_item_ops= _root_item_ops,
.ct_attrs   = gadget_root_attrs,
@@ -1205,11 +1216,10 @@ int composite_os_desc_req_prepare(struct 
usb_composite_dev *cdev,
 static void purge_configs_funcs(struct gadget_info *gi)
 {
struct usb_configuration*c;
+   struct usb_function *f, *tmp;
+   struct config_usb_cfg *cfg;
 
list_for_each_entry(c, >cdev.configs, list) {
-   struct usb_function *f, *tmp;
-   struct config_usb_cfg *cfg;
-
cfg = container_of(c, struct config_usb_cfg, c);
 
list_for_each_entry_safe(f, tmp, >functions, list) {
@@ -1229,6 +1239,14 @@ static void purge_configs_funcs(struct gadget_info *gi)
c->highspeed = 0;
c->fullspeed = 0;
}
+
+   cfg = >control_config;
+   c = >c;
+   list_for_each_entry_safe(f, tmp, >functions, list) {
+   list_move_tail(>list, >func_list);
+   if (f->unbind)
+   f->unbind(c, f);
+   }
 }
 
 static int configfs_composite_bind(struct usb_gadget *gadget,
@@ -1242,6 +1260,9 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
struct usb_string   *s;
unsignedi;
int ret;
+   struct config_usb_cfg *cfg;
+   struct usb_function *f;
+   struct usb_function *tmp;
 
/* the gi->lock is hold by the caller */
cdev->gadget = gadget;
@@ -1260,8 +1281,6 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
 
 
list_for_each_entry(c, >cdev.configs, list) {
-   struct config_usb_cfg *cfg;
-
cfg = container_of(c, struct config_usb_cfg, c);
if (list_empty(>func_list)) {
pr_err("Config %s/%d of %s needs at least one 
function.\n",
@@ -1320,9 +1339,6 @@ static int configfs_composite_bind(struct 

[PATCH 2/3] usb: gadget: f_fs: Add FUNCTIONFS_CONTROL_ONLY flag

[Jerry Zhang]

This flag allows users to directly specify when
they want a ffs instance to be used for handling
control requests only via the configfs control_config/
group. When the flag is set, user must set *none*
of the speed descriptor flags and provide no
speeds in the descriptor. This ensures that it
cannot be mixed up with a normal function.

Signed-off-by: Jerry Zhang 
---
 drivers/usb/gadget/function/f_fs.c  | 22 +++---
 include/uapi/linux/usb/functionfs.h |  1 +
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index a6868f936c78..ddec3606c0e1 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -339,11 +339,6 @@ static ssize_t ffs_ep0_write(struct file *file, const char 
__user *buf,
case FFS_READ_DESCRIPTORS:
case FFS_READ_STRINGS:
/* Copy data */
-   if (unlikely(len < 16)) {
-   ret = -EINVAL;
-   break;
-   }
-
data = ffs_prepare_buffer(buf, len);
if (IS_ERR(data)) {
ret = PTR_ERR(data);
@@ -2393,10 +2388,19 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
  FUNCTIONFS_VIRTUAL_ADDR |
  FUNCTIONFS_EVENTFD |
  FUNCTIONFS_ALL_CTRL_RECIP |
- FUNCTIONFS_CONFIG0_SETUP)) {
+ FUNCTIONFS_CONFIG0_SETUP |
+ FUNCTIONFS_CONTROL_ONLY)) {
ret = -ENOSYS;
goto error;
}
+   if ((bool) (flags & (FUNCTIONFS_HAS_FS_DESC |
+ FUNCTIONFS_HAS_HS_DESC |
+ FUNCTIONFS_HAS_SS_DESC)) ==
+   (bool) (flags & FUNCTIONFS_CONTROL_ONLY)) {
+   pr_err("Must have at least one speed descriptor "
+   "or CONTROL_ONLY (but not both)\n");
+   goto error;
+   }
data += 12;
len  -= 12;
break;
@@ -2476,7 +2480,7 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
len -= ret;
}
 
-   if (raw_descs == data || len) {
+   if (len) {
ret = -EINVAL;
goto error;
}
@@ -3030,10 +3034,6 @@ static int _ffs_func_bind(struct usb_configuration *c,
 
ENTER();
 
-   /* Has descriptors only for speeds gadget does not support */
-   if (unlikely(!(full | high | super)))
-   return -ENOTSUPP;
-
/* Allocate a single chunk, less management later on */
vlabuf = kzalloc(vla_group_size(d), GFP_KERNEL);
if (unlikely(!vlabuf))
diff --git a/include/uapi/linux/usb/functionfs.h 
b/include/uapi/linux/usb/functionfs.h
index d77ee6b65328..25e55f485a6e 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -24,6 +24,7 @@ enum functionfs_flags {
FUNCTIONFS_EVENTFD = 32,
FUNCTIONFS_ALL_CTRL_RECIP = 64,
FUNCTIONFS_CONFIG0_SETUP = 128,
+   FUNCTIONFS_CONTROL_ONLY = 256,
 };
 
 /* Descriptor of an non-audio endpoint */
-- 
2.18.0.399.gad0ab374a1-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 3/3] Documentation: usb: Add docs for configfs control requests

[Jerry Zhang]

Add explanation and examples of how to set up
control request handling with configfs.

Signed-off-by: Jerry Zhang 
---
Changes in V2:
Added changelog text

 Documentation/usb/gadget_configfs.txt | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/Documentation/usb/gadget_configfs.txt 
b/Documentation/usb/gadget_configfs.txt
index b8cb38a98c19..64f69dd3f123 100644
--- a/Documentation/usb/gadget_configfs.txt
+++ b/Documentation/usb/gadget_configfs.txt
@@ -285,6 +285,40 @@ e.g.:
 
 $ rmdir g1
 
+8. Handling control requests
+--
+
+A composite gadget with changing configurations may still want to handle
+vendor control requests in a centralized location. In particular, functionfs
+instances can pass control requests to user-space, but there is no
+guarantee that a functionfs is in the current config.
+
+To handle this there is a special config in the root of the gadget
+called control_config. Functions linked here do not appear in the
+configuration, but will receive control requests. To use it:
+
+Create a special instance of functionfs.
+
+$ mkdir functions/ffs.ctrl
+
+Mount the functionfs instance and write descriptors.
+
+mount functionfs ctrl /dev/ffs-ctrl
+# Write functionfs descriptors to /dev/ffs-ctrl/ep0
+# Descriptor header must include ALL_CTRL_RECIP AND CONTROL_ONLY
+# and must *not* include any speed descriptors.
+
+Link the function into control config.
+
+$ ln -s functions/ffs.ctrl control_config/f1
+
+Link normal functions into the appropriate config, and enable the gadget.
+
+$ echo  > UDC
+
+Handle control requests in /dev/ffs-ctrl/ep0. 
+See functionfs documentation on how to do this.
+
 
 
 
-- 
2.18.0.399.gad0ab374a1-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: dwc2: crash regression in commit 3bc04e28a030 (bisected)

[Antti Seppälä]

On 3 July 2018 at 09:56, Doug Anderson  wrote:
> Hi,
>
> On Sun, Jul 1, 2018 at 11:30 PM, Antti Seppälä  wrote:
>> On 30 June 2018 at 02:57, Doug Anderson  wrote:
>>> Hi,
>>>
>>> On Fri, Jun 29, 2018 at 11:29 AM, Antti Seppälä  wrote:
 Hi Doug, John and linux-usb.

 I'd like to report a regression in commit 3bc04e28a030 (usb: dwc2:
 host: Get aligned DMA in a more supported way)
>>>
>>> Seems unlikely, but any chance that
>>>  helps you?
>>>
>>
>> Thank you for your suggestion but unfortunately the patch does not
>> help and the crash remains.
>
> A few more shots in the dark in case they help:
>
> 1. For the kmalloc() in dwc2_alloc_dma_aligned_buffer(), change from:
>
> kmalloc_ptr = kmalloc(kmalloc_size, mem_flags);
>
> to:
>
> kmalloc_ptr = kmalloc(kmalloc_size, mem_flags | GFP_DMA);
>
>
> The old code used to hardcode this, so maybe it somehow makes a difference?
>

I tried this but it did not have any effect on the crash.

> ---
>
> 2. Change DWC2_USB_DMA_ALIGN to a larger size.  Maybe 32 or 64?
>

I tried these values too but they did not help. It seems to me that
these change the alignment of the start of the struct
dma_aligned_buffer but since the issue is with the alignment of ->data
inside that struct it is always moved to an unaligned location (offset
by the two pointers at the start of the struct).

There is even a mention of this requirement in Documentation/DMA-API.txt:

  Memory coherency operates at a granularity called the cache
  line width.  In order for memory mapped by this API to operate
  correctly, the mapped region must begin exactly on a cache line
  boundary and end exactly on one (to prevent two separately mapped
  regions from sharing a single cache line).  Since the cache line size
  may not be known at compile time, the API will not enforce this
  requirement.  Therefore, it is recommended that driver writers who
  don't take special care to determine the cache line size at run time
  only map virtual regions that begin and end on page boundaries (which
  are guaranteed also to be cache line boundaries).


> ---
>
> 3. Undo just the part of the patch that removed:
>
> /*
>  * Clip max_transfer_size to 65535. dwc2_hc_setup_align_buf() allocates
>  * coherent buffers with this size, and if it's too large we can
>  * exhaust the coherent DMA pool.
>  */
> if (hw->max_transfer_size > 65535)
>   hw->max_transfer_size = 65535;
>
> Maybe there's something on your platform where you have a problem with
> big transfers?
>

I tried adding back this one as well but unfortunately no help from that either.

Then I wrote a proof-of-concept patch that really solves the issue for me.

The patch allocates additional space at the end of that temp bounce
buffer and stores the original value of urb->transfer_buffer there for
keeping until it is needed again.

This way the bounce buffer for DMA is aligned on a page boundary that
is compliant from DMA-API.txt perspective.

Any thoughts or comments? If the patch doesn't look too crazy I can
send it properly with git.

-- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2606,34 +2606,28 @@

 #define DWC2_USB_DMA_ALIGN 4

-struct dma_aligned_buffer {
-void *kmalloc_ptr;
-void *old_xfer_buffer;
-u8 data[0];
-};
-
 static void dwc2_free_dma_aligned_buffer(struct urb *urb)
 {
-struct dma_aligned_buffer *temp;
+void *stored_xfer_buffer;

 if (!(urb->transfer_flags & URB_ALIGNED_TEMP_BUFFER))
 return;

-temp = container_of(urb->transfer_buffer,
-struct dma_aligned_buffer, data);
+memcpy(_xfer_buffer, urb->transfer_buffer +
+urb->transfer_buffer_length, sizeof(void *));

 if (usb_urb_dir_in(urb))
-memcpy(temp->old_xfer_buffer, temp->data,
+memcpy(stored_xfer_buffer, urb->transfer_buffer,
urb->transfer_buffer_length);
-urb->transfer_buffer = temp->old_xfer_buffer;
-kfree(temp->kmalloc_ptr);
+kfree(urb->transfer_buffer);
+urb->transfer_buffer = stored_xfer_buffer;

 urb->transfer_flags &= ~URB_ALIGNED_TEMP_BUFFER;
 }

 static int dwc2_alloc_dma_aligned_buffer(struct urb *urb, gfp_t mem_flags)
 {
-struct dma_aligned_buffer *temp, *kmalloc_ptr;
+void *kmalloc_ptr;
 size_t kmalloc_size;

 if (urb->num_sgs || urb->sg ||
@@ -2641,22 +2635,21 @@
 !((uintptr_t)urb->transfer_buffer & (DWC2_USB_DMA_ALIGN - 1)))
 return 0;

-/* Allocate a buffer with enough padding for alignment */
-kmalloc_size = urb->transfer_buffer_length +
-sizeof(struct dma_aligned_buffer) + DWC2_USB_DMA_ALIGN - 1;
+/* Allocate a buffer with enough padding for original pointer */
+kmalloc_size = urb->transfer_buffer_length + sizeof(void *);

 kmalloc_ptr = kmalloc(kmalloc_size, 

Re: [PATCH v3 1/3] usb: dwc3: pci: Add GPIO lookup table on platforms without ACPI GPIO resources

[Hans de Goede]

Hi,

On 10-06-18 16:01, Hans de Goede wrote:

Bay Trail / BYT SoCs do not have a builtin device-mode phy, instead
they require an external ULPI phy for device-mode.

Only some BYT devices have an external phy, but even on those devices
device-mode is not working because the dwc3 does not see the phy.

The problem is that the ACPI fwnode for the dwc3 does not contain the
expected GPIO resources for the GPIOs connected to the chip-select and
reset pins of the phy.

I've found the workaround which some Android x86 kernels use for this:
https://github.com/BORETS24/Kernel-for-Asus-Zenfone-2/blob/master/arch/x86/platform/intel-mid/device_libs/pci/platform_usb_otg.c
Which boils down to hardcoding the GPIOs for these devices.

The good news it that all boards (*) use the same GPIOs.

This commit fixes the ULPI phy not woring by adding a gpiod_lookup_table
call which adds a hardcoded mapping for BYT devices. Note that the mapping
added by gpiod_add_lookup_table is a fallback mapping, so boards which
properly provide GPIO resources in the ACPI firmware-node resources
will not use this.

*) Except for the first revision of the evalulation-kit, which normal users
don't have

Signed-off-by: Hans de Goede 
---
Changes in v3:
-Add the mapping with gpiod_add_lookup_table() unconditionally on BYT
  devices, as they are only used after checking for GPIO resources in ACPI


Ping? AFAIK this series is ready for merging now and it is necessary to
make gadget mode work on all Bay Trail devices which support gadget
mode.

Regards,

Hans




---
  drivers/usb/dwc3/dwc3-pci.c | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index c961a94d136b..c58f87b01ac7 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -66,6 +67,15 @@ static const struct acpi_gpio_mapping acpi_dwc3_byt_gpios[] = {

{ },
  };
  
+static struct gpiod_lookup_table platform_bytcr_gpios = {

+   .dev_id = ":00:16.0",
+   .table  = {
+   GPIO_LOOKUP("INT33FC:00", 54, "reset", GPIO_ACTIVE_HIGH),
+   GPIO_LOOKUP("INT33FC:02", 14, "cs", GPIO_ACTIVE_HIGH),
+   {}
+   },
+};
+
  static int dwc3_pci_quirks(struct dwc3_pci *dwc)
  {
struct platform_device  *dwc3 = dwc->dwc3;
@@ -126,6 +136,13 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
if (ret)
dev_dbg(>dev, "failed to add mapping 
table\n");
  
+			/*

+* A lot of BYT devices lack ACPI resource entries for
+* the GPIOs, add a fallback mapping to the reference
+* design GPIOs which all boards seem to use.
+*/
+   gpiod_add_lookup_table(_bytcr_gpios);
+
/*
 * These GPIOs will turn on the USB2 PHY. Note that we 
have to
 * put the gpio descriptors again here because the phy 
driver
@@ -256,6 +273,7 @@ static void dwc3_pci_remove(struct pci_dev *pci)
  {
struct dwc3_pci *dwc = pci_get_drvdata(pci);
  
+	gpiod_remove_lookup_table(_bytcr_gpios);

  #ifdef CONFIG_PM
cancel_work_sync(>wakeup_work);
  #endif


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

[Shawn Guo]

On Tue, Jul 03, 2018 at 07:52:07AM -0300, Fabio Estevam wrote:
> Hi Shawn,
> 
> On Tue, Jul 3, 2018 at 12:40 AM, Shawn Guo  wrote:
> 
> > We can have the options in defconfig, but they can still be turned off
> > for whatever reason and we get the hang.  Really, missing a user
> > selectable option in defconfig shouldn't result in a system hang.
> 
> Yes, 100% agree and this is exactly what this USB patch is all about :-)
> 
> The whole point of this USB patch is not to let the the system to hang
> when the defconfig options are turned off.
> 
> It will warn the user that CONFIG_USB_CHIPIDEA_ULPI needs to be
> selected, will propagate an error, but at least the system will not
> hang.
> 
> The user will certainly notice the big warning which says "Select
> CONFIG_USB_CHIPIDEA_ULPI in order to use ULPI mode"
> 
> Please check the original patch of this thread:
> https://patchwork.kernel.org/patch/10486371/

I'm still not convinced this is the best way to go.  But that's USB
maintainer's call.  I will just apply defconfig patches which shouldn't
hurt anyway.

Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

[Fabio Estevam]

Hi Shawn,

On Tue, Jul 3, 2018 at 12:40 AM, Shawn Guo  wrote:

> We can have the options in defconfig, but they can still be turned off
> for whatever reason and we get the hang.  Really, missing a user
> selectable option in defconfig shouldn't result in a system hang.

Yes, 100% agree and this is exactly what this USB patch is all about :-)

The whole point of this USB patch is not to let the the system to hang
when the defconfig options are turned off.

It will warn the user that CONFIG_USB_CHIPIDEA_ULPI needs to be
selected, will propagate an error, but at least the system will not
hang.

The user will certainly notice the big warning which says "Select
CONFIG_USB_CHIPIDEA_ULPI in order to use ULPI mode"

Please check the original patch of this thread:
https://patchwork.kernel.org/patch/10486371/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Particular USB port does not work with certain wifi usb device xhci_hcd

[Jonny Grant]

Hi here

There are a lot of emails on this list. Do you use a bug tracker?

Otherwise, I can unsubscribe, and anyone can email me on j...@jguk.org if 
they want to work on it.


Regards
Jonny


On 02/07/18 21:20, Jonny Grant wrote:

Hi!

My ZyDAS USB wifi works well on other laptop, and this laptop in 2 ports, but 
not a particular 1 port. That port does work with USB mouse tough - so I don't 
think it is a hardware issue.

4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 
x86_64 GNU/Linux

Is there a problem with the driver?

let me know if any other info needed!


Jul  2 10:30:46 asus kernel: [40466.301834] usb 3-2: new high-speed USB device 
number 24 using xhci_hcd
Jul  2 10:30:46 asus kernel: [40466.429772] usb 3-2: device descriptor read/64, 
error -71
Jul  2 10:30:46 asus kernel: [40466.665802] usb 3-2: device descriptor read/64, 
error -71
Jul  2 10:30:46 asus kernel: [40466.901783] usb 3-2: new high-speed USB device 
number 25 using xhci_hcd
Jul  2 10:30:47 asus kernel: [40467.029797] usb 3-2: device descriptor read/64, 
error -71
Jul  2 10:30:47 asus kernel: [40467.265769] usb 3-2: device descriptor read/64, 
error -71
Jul  2 10:30:47 asus kernel: [40467.373859] usb usb3-port2: attempt power cycle
Jul  2 10:30:48 asus kernel: [40468.025748] usb 3-2: new high-speed USB device 
number 26 using xhci_hcd
Jul  2 10:30:48 asus kernel: [40468.025842] usb 3-2: Device not responding to 
setup address.
Jul  2 10:30:48 asus kernel: [40468.233839] usb 3-2: Device not responding to 
setup address.
Jul  2 10:30:48 asus kernel: [40468.441770] usb 3-2: device not accepting 
address 26, error -71
Jul  2 10:30:48 asus kernel: [40468.569748] usb 3-2: new high-speed USB device 
number 27 using xhci_hcd
Jul  2 10:30:48 asus kernel: [40468.569868] usb 3-2: Device not responding to 
setup address.
Jul  2 10:30:48 asus kernel: [40468.777897] usb 3-2: Device not responding to 
setup address.
Jul  2 10:30:49 asus kernel: [40468.985722] usb 3-2: device not accepting 
address 27, error -71
Jul  2 10:30:49 asus kernel: [40468.985788] usb usb3-port2: unable to enumerate 
USB device



I had opened bug here before
https://bugzilla.kernel.org/show_bug.cgi?id=200391

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/5] Migrate AM35xx MUSB glue to device tree and enable MUSB

[Tony Lindgren]

* Adam Ford  [180624 17:15]:
> 
> It currently doesnt' work, but I am looking for ideas on
> what I may have missed or done incorrectly.  

Check the drivers/phy/ti driver part and make sure that
works and has pins and clocks configured.

The rest should be pretty much generic stuff for musb
as long as the SoC glue layer can deal with the module,
clocks and pins.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/5] ARM: OMAP2+: Add AM3517 MUSB setup to pdata quirks.

[Tony Lindgren]

* Adam Ford  [180625 00:15]:
> The pin muxing and clock definitions for the MUSB controller are
> not done through the same registers/pin mux options, so this
> explicitly configures the registers and pin-mux options for MUSB
> on AM3517-EVM
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
> b/arch/arm/mach-omap2/pdata-quirks.c
> index 7f02743edbe4..e0c7ac2c87c1 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -258,9 +258,28 @@ static void __init omap3_sbc_t3517_legacy_init(void)
>   omap3_sbc_t3517_wifi_init();
>  }
>  
> +/* The pin muxing for AM3517 OTG isn't done through the normal means */
> +static __init void am3517_evm_musb_init(void)
> +{
> + u32 devconf2;
> +
> + /*
> +  * Set up USB clock/mode in the DEVCONF2 register.
> +  */
> + devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
> +
> + /* USB2.0 PHY reference clock is 13 MHz */
> + devconf2 &= ~(CONF2_REFFREQ | CONF2_OTGMODE | CONF2_PHY_GPIOMODE);
> + devconf2 |=  CONF2_REFFREQ_13MHZ | CONF2_SESENDEN | CONF2_VBDTCTEN
> + | CONF2_DATPOL;
> +
> + omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
> +}
> +
>  static void __init am3517_evm_legacy_init(void)
>  {
>   am35xx_emac_reset();
> + am3517_evm_musb_init();
>  }

To me it seems you should do this with a simple drivers/phy driver.
There might be already something similar that you can use, see the
da and dm related drivers under drivers/phy/ti.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: dwc2: crash regression in commit 3bc04e28a030 (bisected)

[Doug Anderson]

Hi,

On Sun, Jul 1, 2018 at 11:30 PM, Antti Seppälä  wrote:
> On 30 June 2018 at 02:57, Doug Anderson  wrote:
>> Hi,
>>
>> On Fri, Jun 29, 2018 at 11:29 AM, Antti Seppälä  wrote:
>>> Hi Doug, John and linux-usb.
>>>
>>> I'd like to report a regression in commit 3bc04e28a030 (usb: dwc2:
>>> host: Get aligned DMA in a more supported way)
>>
>> Seems unlikely, but any chance that
>>  helps you?
>>
>
> Thank you for your suggestion but unfortunately the patch does not
> help and the crash remains.

A few more shots in the dark in case they help:

1. For the kmalloc() in dwc2_alloc_dma_aligned_buffer(), change from:

kmalloc_ptr = kmalloc(kmalloc_size, mem_flags);

to:

kmalloc_ptr = kmalloc(kmalloc_size, mem_flags | GFP_DMA);


The old code used to hardcode this, so maybe it somehow makes a difference?

---

2. Change DWC2_USB_DMA_ALIGN to a larger size.  Maybe 32 or 64?

---

3. Undo just the part of the patch that removed:

/*
 * Clip max_transfer_size to 65535. dwc2_hc_setup_align_buf() allocates
 * coherent buffers with this size, and if it's too large we can
 * exhaust the coherent DMA pool.
 */
if (hw->max_transfer_size > 65535)
  hw->max_transfer_size = 65535;

Maybe there's something on your platform where you have a problem with
big transfers?

===

It feels like there's something unique about your setup since I
haven't heard about this crash and that patch is 1.5 years old.
Certainly it could be the MIPS / Big Endian, but I suppose it could
also be the driver for the USB device you're plugging in.  Any chance
the new code is just tickling a problem in that driver?  Can you
reproduce similar crashes with any other USB devices on your platform?


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] Documentation: usb: Add docs for configfs control requests

[Greg Kroah-Hartman]

On Mon, Jul 02, 2018 at 03:01:03PM -0700, Jerry Zhang wrote:
> Signed-off-by: Jerry Zhang 
> ---
>  Documentation/usb/gadget_configfs.txt | 34 +++
>  1 file changed, 34 insertions(+)

I can't take patches without any changelog text at all, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html