Re: [PATCH 1/2] usbhid: more mice with ALWAYS_POLL
On Thu, 2015-04-02 at 14:26 +0200, Jiri Kosina wrote: > On Wed, 1 Apr 2015, Oliver Neukum wrote: > > > > I am postponing all these before it is clarified that this is indeed a > > > case reporter is able to reproduce on different system as well to rule > > > out > > > the possibility of hub being the actual root cause. > > > > The test has been redone on a different system with a mouse reported to > > be affected and the problem does show up. I have to conclude that the we > > are really a victim of bias here. We thought the issue was rare because > > we never looked for it. > > Ok, this is sad. > > I am now applying these two on the previous ones, and we'll see. If this > becomes a frequently re-appearing topic, we'll have to come up with more > generic aproach. I think it is unacceptable to punish owners of good mice for quirky stuff, yet the current approach of manually setting quirks from a module option or adding them to the blacklist has drawbacks. 1. It is slow and cumbersome (especially the blacklist) 2. adding the quirk requires root rights, foreknowledge and is limited to 4 devices So at this point. I'd say the best option would be to have a module parameter to tell HID that it should assume all devices to be quirky. Regards Oliver -- 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: Repeatedly connect/disconnect events for USB devices
On Tue, Apr 07, 2015 at 10:27:15PM +0200, Matthias Nagel wrote: > Obeying to a wish made by Greg Kroah-Hartman I hereby send my bug > report [1] to this list. I do not include the attachments as the can > be found at [1]. The description: Please send the attachments, no one wants to dig for web links :( > The kernel repeatedly reports disconnected event followed by an > immediate connect event for any USB device. Let's call this a > "re-connection event". Sometimes this re-connection events occur in a > burst with dozens in a row before the connection becomes "stable" > again. If at a specific moment in time one device is affected all > other devices might not, but later another device shows the same > problem. This effects all device classes, but the interval between > those re-connection events seems to depend on the device class. > This really sounds like some broken hardware as there's nothing that the kernel can do to disconnect/reconnect a device like this. Given that your hardware works fine in a different machine, I would blame this host controller / internal hub / pci board / motherboard / power supply or some part of that chain. Best of luck, 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
[PATCH] usb: renesas_usbhs: Revise the binding document about the dma-names
Since the DT should describe the hardware (not the driver limitation),
This patch revises the binding document about the dma-names to change
simple numbering as "ch%d" instead of "tx" and "rx".
Also this patch fixes the actual code of renesas_usbhs driver to handle
the new dma-names.
Signed-off-by: Yoshihiro Shimoda
---
This patch is based on Felipe's usb.bit / testing/next branch.
(commit id = bbc78c07a51f6fd29c227b1220a9016e585358ba)
Geert is pointed out about this issue:
https://www.mail-archive.com/devicetree@vger.kernel.org/msg68401.html
.../devicetree/bindings/usb/renesas_usbhs.txt | 6 ++
drivers/usb/renesas_usbhs/fifo.c | 24 ++
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index dc2a18f..ddbe304 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -15,10 +15,8 @@ Optional properties:
- phys: phandle + phy specifier pair
- phy-names: must be "usb"
- dmas: Must contain a list of references to DMA specifiers.
- - dma-names : Must contain a list of DMA names:
- - tx0 ... tx
- - rx0 ... rx
-- This means DnFIFO in USBHS module.
+ - dma-names : named "ch%d", where %d is the channel number ranging from zero
+to the number of channels (DnFIFOs) minus one.
Example:
usbhs: usb@e659 {
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 8597cf9..bc23b4a 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -1227,15 +1227,21 @@ static void usbhsf_dma_init_dt(struct device *dev,
struct usbhs_fifo *fifo,
{
char name[16];
- snprintf(name, sizeof(name), "tx%d", channel);
- fifo->tx_chan = dma_request_slave_channel_reason(dev, name);
- if (IS_ERR(fifo->tx_chan))
- fifo->tx_chan = NULL;
-
- snprintf(name, sizeof(name), "rx%d", channel);
- fifo->rx_chan = dma_request_slave_channel_reason(dev, name);
- if (IS_ERR(fifo->rx_chan))
- fifo->rx_chan = NULL;
+ /*
+* To avoid complex handing for DnFIFOs, the driver uses each
+* DnFIFO as TX or RX direction (not bi-direction).
+* So, the driver uses odd channels for TX, even channels for RX.
+*/
+ snprintf(name, sizeof(name), "ch%d", channel);
+ if (channel & 1) {
+ fifo->tx_chan = dma_request_slave_channel_reason(dev, name);
+ if (IS_ERR(fifo->tx_chan))
+ fifo->tx_chan = NULL;
+ } else {
+ fifo->rx_chan = dma_request_slave_channel_reason(dev, name);
+ if (IS_ERR(fifo->rx_chan))
+ fifo->rx_chan = NULL;
+ }
}
static void usbhsf_dma_init(struct usbhs_priv *priv, struct usbhs_fifo *fifo,
--
1.9.1
--
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] usb: Enable LPM for USB 2.01+ full-speed devices
>> >> USB 2.01+ full-speed devices can have extended descriptor as well >> and can support LPM. > > Yes, they in theory can, but what happens if they are actually > asked to do so? On how many devices have you tested this patch? > I have tested this on Qualcomm USB controller, LPM works. LPM works with same controller with Microsoft Windows as well. I have looked through few Broadcom/CSR controllers, but could not find one that had USB version >= 2.01. Thanks, Rupesh -- 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] usb: Enable LPM for USB 2.01+ full-speed devices
> On Wed, Mar 25, 2015 at 12:23:19PM +0530, rtat...@codeaurora.org wrote: >> From: Rupesh Tatiya >> >> USB 2.01+ full-speed devices can have extended descriptor as well >> and can support LPM. >> >> Change-Id: Ic055d51c02651810d3eb7141bab20a090fe8453b > > We can't take patches with this in it, as it makes no sense in a kernel > changelog :( > > Sorry this is my first time (I read as much as I can before sending patch but not enough I guess). Should I remove "From" line or rephrase commit message? Thanks, Rupesh -- 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 5/5] Documentation: ABI: Fix documentation for mass_storage function
Luns in mass storage function are identified using their id. While creating lun's directory user cannot choose any arbitrary name other than arabic numeral from 1 to FSG_MAX_LUNS. Signed-off-by: Krzysztof Opasiak --- .../ABI/testing/configfs-usb-gadget-mass-storage |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage index 9931fb0..0b54280 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage +++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage @@ -11,10 +11,15 @@ Description: are 2..4. Available only if CONFIG_USB_GADGET_DEBUG_FILES is set. -What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name +What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.id Date: Oct 2013 KernelVersion: 3.13 Description: + id - arabic numeral from 1 to FSG_MAX_LUNS + (which is 8 by default) - 1. LUNs should be numbered contiguously. + lun.0 is reserved for default lun which appears while creating + mass_storage.name directory and cannot be removed by the user. + The attributes: file- The path to the backing file for the LUN. -- 1.7.9.5 -- 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 4/5] usb: gadget: mass_storage: Ensure that lun ids are contiguous
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_mass_storage.c | 35 +++---
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 095b618..9d9fafb 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3355,6 +3355,12 @@ static struct config_group *fsg_lun_make(struct
config_group *group,
goto out;
}
+ if (!fsg_opts->common->luns[num - 1]) {
+ ret = -EINVAL;
+ pr_err("LUN ids should be contignous\n");
+ goto out;
+ }
+
opts = kzalloc(sizeof(*opts), GFP_KERNEL);
if (!opts) {
ret = -ENOMEM;
@@ -3364,12 +3370,17 @@ static struct config_group *fsg_lun_make(struct
config_group *group,
memset(&config, 0, sizeof(config));
config.removable = true;
+ /* ensure that lun ids are contiguous */
+ ret = configfs_depend_item_unlocked(&(fsg_opts->lun_opts
+ [num - 1]->group.cg_item));
+ if (ret)
+ goto err_free_opts;
+
ret = fsg_common_create_lun(fsg_opts->common, &config, num, name,
(const char **)&group->cg_item.ci_name);
- if (ret) {
- kfree(opts);
- goto out;
- }
+ if (ret)
+ goto err_undepend_item;
+
opts->lun = fsg_opts->common->luns[num];
opts->lun_id = num;
BUG_ON(fsg_opts->lun_opts[num]);
@@ -3382,6 +3393,16 @@ static struct config_group *fsg_lun_make(struct
config_group *group,
out:
mutex_unlock(&fsg_opts->lock);
return ERR_PTR(ret);
+
+err_undepend_item:
+ configfs_undepend_item_unlocked(&(fsg_opts->lun_opts
+ [num - 1]->group.cg_item));
+err_free_opts:
+ kfree(opts);
+
+ mutex_unlock(&fsg_opts->lock);
+ return ERR_PTR(ret);
+
}
static void fsg_lun_drop(struct config_group *group, struct config_item *item)
@@ -3400,10 +3421,16 @@ static void fsg_lun_drop(struct config_group *group,
struct config_item *item)
unregister_gadget_item(gadget);
}
+
+ /* Allow to remove next one */
+ configfs_undepend_item_unlocked(&(fsg_opts->lun_opts
+ [lun_opts->lun_id -
1]->group.cg_item));
+
fsg_common_remove_lun(lun_opts->lun, fsg_opts->common->sysfs);
fsg_opts->common->luns[lun_opts->lun_id] = NULL;
fsg_opts->lun_opts[lun_opts->lun_id] = NULL;
lun_opts->lun_id = 0;
+
mutex_unlock(&fsg_opts->lock);
config_item_put(item);
--
1.7.9.5
--
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 3/5] usb: gadget: mass_storage: Store lun_opts in fsg_opts
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_mass_storage.c |5 +
drivers/usb/gadget/function/f_mass_storage.h |1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 811929c..095b618 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3372,6 +3372,8 @@ static struct config_group *fsg_lun_make(struct
config_group *group,
}
opts->lun = fsg_opts->common->luns[num];
opts->lun_id = num;
+ BUG_ON(fsg_opts->lun_opts[num]);
+ fsg_opts->lun_opts[num] = opts;
mutex_unlock(&fsg_opts->lock);
config_group_init_type_name(&opts->group, name, &fsg_lun_type);
@@ -3400,6 +3402,7 @@ static void fsg_lun_drop(struct config_group *group,
struct config_item *item)
fsg_common_remove_lun(lun_opts->lun, fsg_opts->common->sysfs);
fsg_opts->common->luns[lun_opts->lun_id] = NULL;
+ fsg_opts->lun_opts[lun_opts->lun_id] = NULL;
lun_opts->lun_id = 0;
mutex_unlock(&fsg_opts->lock);
@@ -3546,6 +3549,7 @@ static struct usb_function_instance *fsg_alloc_inst(void)
if (!opts)
return ERR_PTR(-ENOMEM);
mutex_init(&opts->lock);
+ memset(opts->lun_opts, 0, sizeof(opts->lun_opts));
opts->func_inst.free_func_inst = fsg_free_inst;
opts->common = fsg_common_setup(opts->common);
if (IS_ERR(opts->common)) {
@@ -3569,6 +3573,7 @@ static struct usb_function_instance *fsg_alloc_inst(void)
(const char **)&opts->func_inst.group.cg_item.ci_name);
opts->lun0.lun = opts->common->luns[0];
opts->lun0.lun_id = 0;
+ opts->lun_opts[0] = &opts->lun0;
config_group_init_type_name(&opts->lun0.group, "lun.0", &fsg_lun_type);
opts->default_groups[0] = &opts->lun0.group;
opts->func_inst.group.default_groups = opts->default_groups;
diff --git a/drivers/usb/gadget/function/f_mass_storage.h
b/drivers/usb/gadget/function/f_mass_storage.h
index b4866fc..0a7c656 100644
--- a/drivers/usb/gadget/function/f_mass_storage.h
+++ b/drivers/usb/gadget/function/f_mass_storage.h
@@ -81,6 +81,7 @@ struct fsg_opts {
struct fsg_common *common;
struct usb_function_instance func_inst;
struct fsg_lun_opts lun0;
+ struct fsg_lun_opts *lun_opts[FSG_MAX_LUNS];
struct config_group *default_groups[2];
bool no_configfs; /* for legacy gadgets */
--
1.7.9.5
--
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 2/5] fs: configfs: Add unlocked version of configfs_depend_item()
Sometimes it might be desirable to prohibit removing a directory
in configfs. One example is USB gadget (mass_storage function):
when gadget is already bound, if lun directory is removed,
the gadget must be thrown away, too. A better solution would be
to fail with e.g. -EBUSY.
Currently configfs has configfs_depend/undepend_item() methods
but they cannot be used in configfs callbacks. This commit
adds unlocked version of this methods which can be used
only in configfs callbacks.
Signed-off-by: Krzysztof Opasiak
---
fs/configfs/dir.c| 29 +
include/linux/configfs.h |9 +
2 files changed, 38 insertions(+)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index dee1cb5..ef51594 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1152,6 +1152,35 @@ void configfs_undepend_item(struct configfs_subsystem
*subsys,
}
EXPORT_SYMBOL(configfs_undepend_item);
+int configfs_depend_item_unlocked(struct config_item *target)
+{
+ struct configfs_dirent *sd;
+ int ret = -ENOENT;
+
+ spin_lock(&configfs_dirent_lock);
+ BUG_ON(!target->ci_dentry);
+
+ sd = target->ci_dentry->d_fsdata;
+ if ((sd->s_type & CONFIGFS_DIR) &&
+ ((sd->s_type & CONFIGFS_USET_DROPPING) ||
+(sd->s_type & CONFIGFS_USET_CREATING)))
+ goto out_unlock_dirent_lock;
+
+ sd->s_dependent_count += 1;
+ ret = 0;
+
+out_unlock_dirent_lock:
+ spin_unlock(&configfs_dirent_lock);
+ return ret;
+}
+EXPORT_SYMBOL(configfs_depend_item_unlocked);
+
+void configfs_undepend_item_unlocked(struct config_item *target)
+{
+ configfs_undepend_item(NULL, target);
+}
+EXPORT_SYMBOL(configfs_undepend_item_unlocked);
+
static int configfs_mkdir(struct inode *dir, struct dentry *dentry, umode_t
mode)
{
int ret = 0;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 34025df..e9dbf01 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -257,4 +257,13 @@ void configfs_unregister_subsystem(struct
configfs_subsystem *subsys);
int configfs_depend_item(struct configfs_subsystem *subsys, struct config_item
*target);
void configfs_undepend_item(struct configfs_subsystem *subsys, struct
config_item *target);
+/*
+ * These functions can sleep and can alloc with GFP_KERNEL
+ * NOTE: These should be called only underneath configfs callbacks.
+ * WARNING: These cannot be called on newly created item
+ *(in make_group()/make_item callback)
+ */
+int configfs_depend_item_unlocked(struct config_item *target);
+void configfs_undepend_item_unlocked(struct config_item *target);
+
#endif /* _CONFIGFS_H_ */
--
1.7.9.5
--
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/5] fs: configfs: Fix typo in comment
Signed-off-by: Krzysztof Opasiak --- fs/configfs/dir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c index cf0db00..dee1cb5 100644 --- a/fs/configfs/dir.c +++ b/fs/configfs/dir.c @@ -325,7 +325,7 @@ static void configfs_dir_set_ready(struct configfs_dirent *sd) * attached and not validated yet. * @sd configfs_dirent of the directory to check * - * @return non-zero iff the directory was validated + * @return non-zero if the directory was validated * * Note: takes configfs_dirent_lock, so the result may change from false to true * in two consecutive calls, but never from true to false. -- 1.7.9.5 -- 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 0/5] Ensure that lun ids are contiguous
Dear list, This series fix configfs interface for mass storage function. According to mass storage specification[1]: "Logical Unit Numbers on the device shall be numbered contiguously starting from LUN 0 to a maximum LUN of 15 (Fh)." Currently configfs interface allows to create LUNs with arbitrary ids what causes problems with some host side mass storage drivers. This patch extends configfs interface with unlocked version of configfs_depend_item() which should be used only in configfs callbacks. This allows to protect from removing lun directory from the middle of id space. Example: as is: $ mkdir mass_storage.name $ mkdir lun.3 $ mkdir lun.5 $ rmdir lun.3 After this series: $ mkdir mass_storage.name $ mkdir lun.3 mkdir: cannot create directory 'lun.3': Invalid argument $ mkdir lun.1 $ mkdir lun.2 $ rmdir lun.1 rmdir: failed to remove 'lun.1': Device or resource busy $ rmdir lun.2 $ rmdir lun.1 -- Best regards, Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics Krzysztof Opasiak (5): fs: configfs: Fix typo in comment fs: configfs: Add unlocked version of configfs_depend_item() usb: gadget: mass_storage: Store lun_opts in fsg_opts usb: gadget: mass_storage: Ensure that lun ids are contiguous Documentation: ABI: Fix documentation for mass_storage function .../ABI/testing/configfs-usb-gadget-mass-storage |7 +++- drivers/usb/gadget/function/f_mass_storage.c | 40 ++-- drivers/usb/gadget/function/f_mass_storage.h |1 + fs/configfs/dir.c | 31 ++- include/linux/configfs.h |9 + 5 files changed, 82 insertions(+), 6 deletions(-) -- 1.7.9.5 -- 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] usb: Enable LPM for USB 2.01+ full-speed devices
On Wed, Apr 08, 2015 at 11:27:40AM -, rtat...@codeaurora.org wrote: > > On Wed, Mar 25, 2015 at 12:23:19PM +0530, rtat...@codeaurora.org wrote: > >> From: Rupesh Tatiya > >> > >> USB 2.01+ full-speed devices can have extended descriptor as well > >> and can support LPM. > >> > >> Change-Id: Ic055d51c02651810d3eb7141bab20a090fe8453b > > > > We can't take patches with this in it, as it makes no sense in a kernel > > changelog :( > > > > > > Sorry this is my first time (I read as much as I can before sending patch > but not enough I guess). Should I remove "From" line or rephrase commit > message? >From line is fine. -- 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/4] fs: configfs: Add unlocked version of configfs_depend_item()
Sometimes it might be desirable to prohibit removing a directory
in configfs. One example is USB gadget (mass_storage function):
when gadget is already bound, if lun directory is removed,
the gadget must be thrown away, too. A better solution would be
to fail with e.g. -EBUSY.
Currently configfs has configfs_depend/undepend_item() methods
but they cannot be used in configfs callbacks. This commit
adds unlocked version of this methods which can be used
only in configfs callbacks.
Signed-off-by: Krzysztof Opasiak
---
fs/configfs/dir.c| 29 +
include/linux/configfs.h |9 +
2 files changed, 38 insertions(+)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index cf0db00..7875a5e 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1152,6 +1152,35 @@ void configfs_undepend_item(struct configfs_subsystem
*subsys,
}
EXPORT_SYMBOL(configfs_undepend_item);
+int configfs_depend_item_unlocked(struct config_item *target)
+{
+ struct configfs_dirent *sd;
+ int ret = -ENOENT;
+
+ spin_lock(&configfs_dirent_lock);
+ BUG_ON(!target->ci_dentry);
+
+ sd = target->ci_dentry->d_fsdata;
+ if ((sd->s_type & CONFIGFS_DIR) &&
+ ((sd->s_type & CONFIGFS_USET_DROPPING) ||
+(sd->s_type & CONFIGFS_USET_CREATING)))
+ goto out_unlock_dirent_lock;
+
+ sd->s_dependent_count += 1;
+ ret = 0;
+
+out_unlock_dirent_lock:
+ spin_unlock(&configfs_dirent_lock);
+ return ret;
+}
+EXPORT_SYMBOL(configfs_depend_item_unlocked);
+
+void configfs_undepend_item_unlocked(struct config_item *target)
+{
+ configfs_undepend_item(NULL, target);
+}
+EXPORT_SYMBOL(configfs_undepend_item_unlocked);
+
static int configfs_mkdir(struct inode *dir, struct dentry *dentry, umode_t
mode)
{
int ret = 0;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 34025df..e9dbf01 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -257,4 +257,13 @@ void configfs_unregister_subsystem(struct
configfs_subsystem *subsys);
int configfs_depend_item(struct configfs_subsystem *subsys, struct config_item
*target);
void configfs_undepend_item(struct configfs_subsystem *subsys, struct
config_item *target);
+/*
+ * These functions can sleep and can alloc with GFP_KERNEL
+ * NOTE: These should be called only underneath configfs callbacks.
+ * WARNING: These cannot be called on newly created item
+ *(in make_group()/make_item callback)
+ */
+int configfs_depend_item_unlocked(struct config_item *target);
+void configfs_undepend_item_unlocked(struct config_item *target);
+
#endif /* _CONFIGFS_H_ */
--
1.7.9.5
--
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 2/4] usb: gadget: mass_storage: Store lun_opts in fsg_opts
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_mass_storage.c |5 +
drivers/usb/gadget/function/f_mass_storage.h |1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 811929c..095b618 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3372,6 +3372,8 @@ static struct config_group *fsg_lun_make(struct
config_group *group,
}
opts->lun = fsg_opts->common->luns[num];
opts->lun_id = num;
+ BUG_ON(fsg_opts->lun_opts[num]);
+ fsg_opts->lun_opts[num] = opts;
mutex_unlock(&fsg_opts->lock);
config_group_init_type_name(&opts->group, name, &fsg_lun_type);
@@ -3400,6 +3402,7 @@ static void fsg_lun_drop(struct config_group *group,
struct config_item *item)
fsg_common_remove_lun(lun_opts->lun, fsg_opts->common->sysfs);
fsg_opts->common->luns[lun_opts->lun_id] = NULL;
+ fsg_opts->lun_opts[lun_opts->lun_id] = NULL;
lun_opts->lun_id = 0;
mutex_unlock(&fsg_opts->lock);
@@ -3546,6 +3549,7 @@ static struct usb_function_instance *fsg_alloc_inst(void)
if (!opts)
return ERR_PTR(-ENOMEM);
mutex_init(&opts->lock);
+ memset(opts->lun_opts, 0, sizeof(opts->lun_opts));
opts->func_inst.free_func_inst = fsg_free_inst;
opts->common = fsg_common_setup(opts->common);
if (IS_ERR(opts->common)) {
@@ -3569,6 +3573,7 @@ static struct usb_function_instance *fsg_alloc_inst(void)
(const char **)&opts->func_inst.group.cg_item.ci_name);
opts->lun0.lun = opts->common->luns[0];
opts->lun0.lun_id = 0;
+ opts->lun_opts[0] = &opts->lun0;
config_group_init_type_name(&opts->lun0.group, "lun.0", &fsg_lun_type);
opts->default_groups[0] = &opts->lun0.group;
opts->func_inst.group.default_groups = opts->default_groups;
diff --git a/drivers/usb/gadget/function/f_mass_storage.h
b/drivers/usb/gadget/function/f_mass_storage.h
index b4866fc..0a7c656 100644
--- a/drivers/usb/gadget/function/f_mass_storage.h
+++ b/drivers/usb/gadget/function/f_mass_storage.h
@@ -81,6 +81,7 @@ struct fsg_opts {
struct fsg_common *common;
struct usb_function_instance func_inst;
struct fsg_lun_opts lun0;
+ struct fsg_lun_opts *lun_opts[FSG_MAX_LUNS];
struct config_group *default_groups[2];
bool no_configfs; /* for legacy gadgets */
--
1.7.9.5
--
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 4/4] Documentation: ABI: Fix documentation for mass_storage function
Luns in mass storage function are identified using their id. While creating lun's directory user cannot choose any arbitrary name other than arabic numeral from 1 to FSG_MAX_LUNS. Signed-off-by: Krzysztof Opasiak --- .../ABI/testing/configfs-usb-gadget-mass-storage |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage index 9931fb0..0b54280 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage +++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage @@ -11,10 +11,15 @@ Description: are 2..4. Available only if CONFIG_USB_GADGET_DEBUG_FILES is set. -What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name +What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.id Date: Oct 2013 KernelVersion: 3.13 Description: + id - arabic numeral from 1 to FSG_MAX_LUNS + (which is 8 by default) - 1. LUNs should be numbered contiguously. + lun.0 is reserved for default lun which appears while creating + mass_storage.name directory and cannot be removed by the user. + The attributes: file- The path to the backing file for the LUN. -- 1.7.9.5 -- 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/4] Ensure that lun ids are contiguous
Dear list,
This series fix configfs interface for mass storage function.
According to mass storage specification[1]:
"Logical Unit Numbers on the device shall be numbered contiguously
starting from LUN 0 to a maximum LUN of 15 (Fh)."
Currently configfs interface allows to create LUNs with
arbitrary ids what causes problems with some host side
mass storage drivers.
This patch extends configfs interface with unlocked version
of configfs_depend_item() which should be used only in configfs
callbacks. This allows to protect from
removing lun directory from the middle of id space.
Example:
as is:
$ mkdir mass_storage.name
$ mkdir lun.3
$ mkdir lun.5
$ rmdir lun.3
After this series:
$ mkdir mass_storage.name
$ mkdir lun.3
mkdir: cannot create directory 'lun.3': Invalid argument
$ mkdir lun.1
$ mkdir lun.2
$ rmdir lun.1
rmdir: failed to remove 'lun.1': Device or resource busy
$ rmdir lun.2
$ rmdir lun.1
--
Best regards,
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
---
Changes since v1:
- drop incorrect typo fix
("iff" is not a typo but shorten version of "if and only if")
Krzysztof Opasiak (4):
fs: configfs: Add unlocked version of configfs_depend_item()
usb: gadget: mass_storage: Store lun_opts in fsg_opts
usb: gadget: mass_storage: Ensure that lun ids are contiguous
Documentation: ABI: Fix documentation for mass_storage function
.../ABI/testing/configfs-usb-gadget-mass-storage |7 +++-
drivers/usb/gadget/function/f_mass_storage.c | 40 ++--
drivers/usb/gadget/function/f_mass_storage.h |1 +
fs/configfs/dir.c | 29 ++
include/linux/configfs.h |9 +
5 files changed, 81 insertions(+), 5 deletions(-)
--
1.7.9.5
--
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/4] usb: gadget: mass_storage: Ensure that lun ids are contiguous
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_mass_storage.c | 35 +++---
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 095b618..9d9fafb 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3355,6 +3355,12 @@ static struct config_group *fsg_lun_make(struct
config_group *group,
goto out;
}
+ if (!fsg_opts->common->luns[num - 1]) {
+ ret = -EINVAL;
+ pr_err("LUN ids should be contignous\n");
+ goto out;
+ }
+
opts = kzalloc(sizeof(*opts), GFP_KERNEL);
if (!opts) {
ret = -ENOMEM;
@@ -3364,12 +3370,17 @@ static struct config_group *fsg_lun_make(struct
config_group *group,
memset(&config, 0, sizeof(config));
config.removable = true;
+ /* ensure that lun ids are contiguous */
+ ret = configfs_depend_item_unlocked(&(fsg_opts->lun_opts
+ [num - 1]->group.cg_item));
+ if (ret)
+ goto err_free_opts;
+
ret = fsg_common_create_lun(fsg_opts->common, &config, num, name,
(const char **)&group->cg_item.ci_name);
- if (ret) {
- kfree(opts);
- goto out;
- }
+ if (ret)
+ goto err_undepend_item;
+
opts->lun = fsg_opts->common->luns[num];
opts->lun_id = num;
BUG_ON(fsg_opts->lun_opts[num]);
@@ -3382,6 +3393,16 @@ static struct config_group *fsg_lun_make(struct
config_group *group,
out:
mutex_unlock(&fsg_opts->lock);
return ERR_PTR(ret);
+
+err_undepend_item:
+ configfs_undepend_item_unlocked(&(fsg_opts->lun_opts
+ [num - 1]->group.cg_item));
+err_free_opts:
+ kfree(opts);
+
+ mutex_unlock(&fsg_opts->lock);
+ return ERR_PTR(ret);
+
}
static void fsg_lun_drop(struct config_group *group, struct config_item *item)
@@ -3400,10 +3421,16 @@ static void fsg_lun_drop(struct config_group *group,
struct config_item *item)
unregister_gadget_item(gadget);
}
+
+ /* Allow to remove next one */
+ configfs_undepend_item_unlocked(&(fsg_opts->lun_opts
+ [lun_opts->lun_id -
1]->group.cg_item));
+
fsg_common_remove_lun(lun_opts->lun, fsg_opts->common->sysfs);
fsg_opts->common->luns[lun_opts->lun_id] = NULL;
fsg_opts->lun_opts[lun_opts->lun_id] = NULL;
lun_opts->lun_id = 0;
+
mutex_unlock(&fsg_opts->lock);
config_item_put(item);
--
1.7.9.5
--
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: Occasionally a USB mouse and keyboard connected to a USB hub stop working. Helps recover only reconnect USB hub.
Hi! Excuse me, did not understand your message. You offer to throw out all of the devices that do not work? But this device is works. Very rear occurs described situation. I write here because hope that can make do some thing with kernel. For example software reset hub etc. -- Best Regards, Mike Gavrilov. 2015-03-20 1:51 GMT+05:00 Alan Stern : > On Thu, 19 Mar 2015, Михаил Гаврилов wrote: > >> Occasionally a USB mouse and keyboard connected to a USB hub stop >> working. Helps recover only reconnect USB hub. > > It sounds like something is wrong with the hub. Have you tried > replacing it? > > Alan Stern > -- 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] usb: renesas_usbhs: Revise the binding document about the dma-names
On Wed, Apr 08, 2015 at 11:42:24AM +0100, Yoshihiro Shimoda wrote:
> Since the DT should describe the hardware (not the driver limitation),
> This patch revises the binding document about the dma-names to change
> simple numbering as "ch%d" instead of "tx" and "rx".
The naming given in this patch looks more sensible to me.
> Also this patch fixes the actual code of renesas_usbhs driver to handle
> the new dma-names.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> This patch is based on Felipe's usb.bit / testing/next branch.
> (commit id = bbc78c07a51f6fd29c227b1220a9016e585358ba)
I take it the existing driver and binding haven't hit mainline, and
therefore there are no users yet?
Mark.
>
> Geert is pointed out about this issue:
> https://www.mail-archive.com/devicetree@vger.kernel.org/msg68401.html
>
> .../devicetree/bindings/usb/renesas_usbhs.txt | 6 ++
> drivers/usb/renesas_usbhs/fifo.c | 24
> ++
> 2 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> index dc2a18f..ddbe304 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> @@ -15,10 +15,8 @@ Optional properties:
>- phys: phandle + phy specifier pair
>- phy-names: must be "usb"
>- dmas: Must contain a list of references to DMA specifiers.
> - - dma-names : Must contain a list of DMA names:
> - - tx0 ... tx
> - - rx0 ... rx
> -- This means DnFIFO in USBHS module.
> + - dma-names : named "ch%d", where %d is the channel number ranging from
> zero
> +to the number of channels (DnFIFOs) minus one.
>
> Example:
> usbhs: usb@e659 {
> diff --git a/drivers/usb/renesas_usbhs/fifo.c
> b/drivers/usb/renesas_usbhs/fifo.c
> index 8597cf9..bc23b4a 100644
> --- a/drivers/usb/renesas_usbhs/fifo.c
> +++ b/drivers/usb/renesas_usbhs/fifo.c
> @@ -1227,15 +1227,21 @@ static void usbhsf_dma_init_dt(struct device *dev,
> struct usbhs_fifo *fifo,
> {
> char name[16];
>
> - snprintf(name, sizeof(name), "tx%d", channel);
> - fifo->tx_chan = dma_request_slave_channel_reason(dev, name);
> - if (IS_ERR(fifo->tx_chan))
> - fifo->tx_chan = NULL;
> -
> - snprintf(name, sizeof(name), "rx%d", channel);
> - fifo->rx_chan = dma_request_slave_channel_reason(dev, name);
> - if (IS_ERR(fifo->rx_chan))
> - fifo->rx_chan = NULL;
> + /*
> + * To avoid complex handing for DnFIFOs, the driver uses each
> + * DnFIFO as TX or RX direction (not bi-direction).
> + * So, the driver uses odd channels for TX, even channels for RX.
> + */
> + snprintf(name, sizeof(name), "ch%d", channel);
> + if (channel & 1) {
> + fifo->tx_chan = dma_request_slave_channel_reason(dev, name);
> + if (IS_ERR(fifo->tx_chan))
> + fifo->tx_chan = NULL;
> + } else {
> + fifo->rx_chan = dma_request_slave_channel_reason(dev, name);
> + if (IS_ERR(fifo->rx_chan))
> + fifo->rx_chan = NULL;
> + }
> }
>
> static void usbhsf_dma_init(struct usbhs_priv *priv, struct usbhs_fifo *fifo,
> --
> 1.9.1
>
--
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] usb: Enable LPM for USB 2.01+ full-speed devices
>> On Wed, Mar 25, 2015 at 12:23:19PM +0530, rtat...@codeaurora.org wrote: >>> From: Rupesh Tatiya >>> >>> USB 2.01+ full-speed devices can have extended descriptor as well >>> and can support LPM. >>> >>> Change-Id: Ic055d51c02651810d3eb7141bab20a090fe8453b >> >> We can't take patches with this in it, as it makes no sense in a kernel >> changelog :( >> >> > > Sorry this is my first time (I read as much as I can before sending patch > but not enough I guess). Should I remove "From" line or rephrase commit > message? Rupesh, Just remove below line from commit message: >>> Change-Id: Ic055d51c02651810d3eb7141bab20a090fe8453b > > Thanks, > Rupesh > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - Pramod -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 2/4] usb: gadget: mass_storage: Store lun_opts in fsg_opts
On Wed, 8 Apr 2015, Krzysztof Opasiak wrote:
> Signed-off-by: Krzysztof Opasiak
> ---
> drivers/usb/gadget/function/f_mass_storage.c |5 +
> drivers/usb/gadget/function/f_mass_storage.h |1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/usb/gadget/function/f_mass_storage.c
> b/drivers/usb/gadget/function/f_mass_storage.c
> index 811929c..095b618 100644
> --- a/drivers/usb/gadget/function/f_mass_storage.c
> +++ b/drivers/usb/gadget/function/f_mass_storage.c
> @@ -3372,6 +3372,8 @@ static struct config_group *fsg_lun_make(struct
> config_group *group,
> }
> opts->lun = fsg_opts->common->luns[num];
> opts->lun_id = num;
> + BUG_ON(fsg_opts->lun_opts[num]);
This is not a good idea. BUG_ON should hardly ever be used. In fact,
Linus has said that the only time BUG_ON should be used is when things
are so badly messed up that it is better to crash the computer than to
let it continue.
What's wrong with using WARN_ON instead?
> diff --git a/drivers/usb/gadget/function/f_mass_storage.h
> b/drivers/usb/gadget/function/f_mass_storage.h
> index b4866fc..0a7c656 100644
> --- a/drivers/usb/gadget/function/f_mass_storage.h
> +++ b/drivers/usb/gadget/function/f_mass_storage.h
> @@ -81,6 +81,7 @@ struct fsg_opts {
> struct fsg_common *common;
> struct usb_function_instance func_inst;
> struct fsg_lun_opts lun0;
> + struct fsg_lun_opts *lun_opts[FSG_MAX_LUNS];
This looks strange. Why is the entry for LUN 0 duplicated?
Alan Stern
--
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: Occasionally a USB mouse and keyboard connected to a USB hub stop working. Helps recover only reconnect USB hub.
On Wed, 8 Apr 2015, Михаил Гаврилов wrote: > Hi! > Excuse me, did not understand your message. > You offer to throw out all of the devices that do not work? No, you don't have to throw out all the devices. Just try a different hub. > But this > device is works. Very rear occurs described situation. In other words, the hub very rarely stops working. If the problem is very rare then you shouldn't worry about it. But if the problem bothers you then you should try using a different hub. > I write here because hope that can make do some thing with kernel. For > example software reset hub etc. There is a program you can use to reset the hub manually: http://marc.info/?l=linux-usb&m=126028634531290&w=2 I don't know if the kernel can detect the problem automatically, however. Alan Stern -- 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: Unable to access USB mass storage device with xhci. okay with ehci
On Wed, 8 Apr 2015, Steve Bangert wrote: > What i did was not correct, usb-storage.quirks=174c:55aa:u was added to > /etc/default/grub file after GRUB_CMDLINE_LINUX="rhgb quiet", using > the grub-configurator tool > followed by a reboot and i now have a working usb storage device > using xhci. Here's the usbmon trace and the dmesg log is attached. > > I also found a comment in the source code file (uas-detect.h see > attached) that states that my device, the ASMedia bridge is not > supported by the uas driver. The comment does not say that. It refers to a different model from yours. You can tell because the comment says that the non-working ASM1051 supports 32 streams, whereas your device supports 16. In fact, as far as I can tell, your device _does_ work with the uas driver provided max_sectors isn't too high (i.e., <= 240, which is the default value used by usb-storage). Unfortunately, the uas driver doesn't provide any way to set max_sectors. You can test this by adding a line that says: .max_sectors = 240, anywhere inside the definition of uas_host_template in the uas.c source file. > So my next question is there a way to bind usb-storage to this device > and have a working device out of the box without the hassle of adding > a module parameter? We should ask Hans, since he wrote the comment and code in uas-detect.h and presumably has a better understanding of the situation. Alan Stern -- 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 2/4] usb: gadget: mass_storage: Store lun_opts in fsg_opts
Hi,
On 04/08/2015 04:15 PM, Alan Stern wrote:> On Wed, 8 Apr 2015, Krzysztof
Opasiak wrote:
>
>> Signed-off-by: Krzysztof Opasiak
>> ---
>> drivers/usb/gadget/function/f_mass_storage.c |5 +
>> drivers/usb/gadget/function/f_mass_storage.h |1 +
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
>> index 811929c..095b618 100644
>> --- a/drivers/usb/gadget/function/f_mass_storage.c
>> +++ b/drivers/usb/gadget/function/f_mass_storage.c
>> @@ -3372,6 +3372,8 @@ static struct config_group
*fsg_lun_make(struct config_group *group,
>>}
>>opts->lun = fsg_opts->common->luns[num];
>>opts->lun_id = num;
>> + BUG_ON(fsg_opts->lun_opts[num]);
>
> This is not a good idea. BUG_ON should hardly ever be used. In fact,
> Linus has said that the only time BUG_ON should be used is when things
> are so badly messed up that it is better to crash the computer than to
> let it continue.
>
> What's wrong with using WARN_ON instead?
Nothing. I have simply used BUG_ON() because this situation should never
happen. If it happed then we made some mess in luns and there is no easy
way to recovery from this point. This is only a little defense point for
future to make debugging easier. I may change this to WARN_ON() if you like.
>
>> diff --git a/drivers/usb/gadget/function/f_mass_storage.h
b/drivers/usb/gadget/function/f_mass_storage.h
>> index b4866fc..0a7c656 100644
>> --- a/drivers/usb/gadget/function/f_mass_storage.h
>> +++ b/drivers/usb/gadget/function/f_mass_storage.h
>> @@ -81,6 +81,7 @@ struct fsg_opts {
>>struct fsg_common *common;
>>struct usb_function_instance func_inst;
>>struct fsg_lun_opts lun0;
>> + struct fsg_lun_opts *lun_opts[FSG_MAX_LUNS];
>
> This looks strange. Why is the entry for LUN 0 duplicated?
LUN 0 is created on mkdir and cannot be removed by user so the memory
for it is allocated together with fsg_opts structure. Rest of LUNs are
being created by explicit user action and malloc() separately. This
array is used to store their pointers. To make the code easier we simply:
lun_opts[0] = &fsg_opts->lun0;
so later we don't care which lun we are dealing with.
--
Best regards,
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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: Repeatedly connect/disconnect events for USB devices
Am Mittwoch, 8. April 2015, 10:40:39 schrieb Greg KH: > > Please send the attachments, no one wants to dig for web links :( Here they are. > > This really sounds like some broken hardware as there's nothing that the > kernel can do to disconnect/reconnect a device like this. Given that > your hardware works fine in a different machine, I would blame this host > controller / internal hub / pci board / motherboard / power supply or > some part of that chain. > I do not believe it is broken a controller/interal hub/pci/etc., because under Windows everything works fine. There are three scenarios: (a) same external USB hardware at a different machine running Linux 3.18.9 --> OK (b) same external USB hardware at the affected machine running Windows 7 --> OK (c) same external USB hardware at the affected machine running Linux 3.18.9 --> FAIL Due to (a) I know that the devices are supported by Linux. Due to (b) I can exclude a problem with the host controller / internal hub / etc. My best guess it that the particular combination of kernel driver and host controller is to blame for the problem. The other machine is rahter old and has only USB 2.0 ports. The affacted machine has a ASUS P9D WS motherboard and a mix of USB 2.0 and 3.0 ports. Unfortunately, I am to little of a kernel hacker to investigate the problem any further without external advice. Matthias [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.12.21-gentoo (root@matthias-pc) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #1 SMP Wed Jun 4 18:46:40 CEST 2014 [0.00] Command line: \EFI\gentoo\bzImage-3.12.21 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved [0.00] BIOS-e820: [mem 0x0010-0xcb662fff] usable [0.00] BIOS-e820: [mem 0xcb663000-0xcb669fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcb66a000-0xcbab3fff] usable [0.00] BIOS-e820: [mem 0xcbab4000-0xcbef1fff] reserved [0.00] BIOS-e820: [mem 0xcbef2000-0xdd7a5fff] usable [0.00] BIOS-e820: [mem 0xdd7a6000-0xdd9adfff] reserved [0.00] BIOS-e820: [mem 0xdd9ae000-0xdd9c3fff] ACPI data [0.00] BIOS-e820: [mem 0xdd9c4000-0xddf07fff] ACPI NVS [0.00] BIOS-e820: [mem 0xddf08000-0xdeffefff] reserved [0.00] BIOS-e820: [mem 0xdefff000-0xdeff] usable [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00041eff] usable [0.00] e820: update [mem 0xcb13d018-0xcb15cc57] usable ==> usable [0.00] e820: update [mem 0xcb12c018-0xcb13c057] usable ==> usable [0.00] e820: update [mem 0xcb11b018-0xcb12b057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x00057fff] usable [0.00] reserve setup_data: [mem 0x00058000-0x00058fff] reserved [0.00] reserve setup_data: [mem 0x00059000-0x0009efff] usable [0.00] reserve setup_data: [mem 0x0009f000-0x0009] reserved [0.00] reserve setup_data: [mem 0x0010-0xcb11b017] usable [0.00] reserve setup_data: [mem 0xcb11b018-0xcb12b057] usable [0.00] reserve setup_data: [mem 0xcb12b058-0xcb12c017] usable [0.00] reserve setup_data: [mem 0xcb12c018-0xcb13c057] usable [0.00] reserve setup_data: [mem 0xcb13c058-0xcb13d017] usable [0.00] reserve setup_data: [mem 0xcb13d018-0xcb15cc57] usable [0.00] reserve setup_data: [mem 0xcb15cc58-0xcb662fff] usable [0.00] reserve setup_data: [mem 0xcb663000-0xcb669fff] ACPI NVS [0.00] reserve setup_data: [mem 0xcb66a000-0xcbab3fff] usable [0.00] reserve setup_data: [mem 0xcbab4000-0xcbef1fff] reserved [0.00] reserve setup_data: [mem 0xcbef2000-0xdd7a5ff
[PATCHv2] dma: cppi41: add missing bitfields
Add missing directions, residue_granularity,
srd_addr_widths and dst_addr_widths bitfields.
Without those we will see a kernel WARN()
when loading musb on am335x devices.
Signed-off-by: Felipe Balbi
---
retested with AM335x BeagleBone Black
drivers/dma/cppi41.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 512cb8e2805e..ceedafbd23e0 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -903,6 +903,11 @@ static const struct cppi_glue_infos *get_glue_info(struct
device *dev)
return of_id->data;
}
+#define CPPI41_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+ BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+ BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
+ BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
static int cppi41_dma_probe(struct platform_device *pdev)
{
struct cppi41_dd *cdd;
@@ -926,6 +931,10 @@ static int cppi41_dma_probe(struct platform_device *pdev)
cdd->ddev.device_issue_pending = cppi41_dma_issue_pending;
cdd->ddev.device_prep_slave_sg = cppi41_dma_prep_slave_sg;
cdd->ddev.device_terminate_all = cppi41_stop_chan;
+ cdd->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ cdd->ddev.src_addr_widths = CPPI41_DMA_BUSWIDTHS;
+ cdd->ddev.dst_addr_widths = CPPI41_DMA_BUSWIDTHS;
+ cdd->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
cdd->ddev.dev = dev;
INIT_LIST_HEAD(&cdd->ddev.channels);
cpp41_dma_info.dma_cap = cdd->ddev.cap_mask;
--
2.3.0
--
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: Question: drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback()
Everyone, thank you for your attention and suggestions.
Johan, perfect, thank you, that did indeed help and has fixed the issue I was
seeing.
The change replaced dev_err() with dev_dbg() -- thus not logging (by default)
what
was a very noisy flood of messages. Does that simply change timing enough such
that
the USB HCD has time to process the disconnect? Or is there something else going
on that I'm missing?
Thank you,
~Mark
> -Original Message-
> From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
> Sent: Tuesday, April 07, 2015 2:58 PM
> To: Mark Enstone
> Cc: linux-usb@vger.kernel.org
> Subject: Re: Question: drivers/usb/serial/generic.c:
> usb_serial_generic_read_bulk_callback()
>
> > Question: have you seen such behavior?
>
> Yes, I just debugged a related issue where using large unaligned buffers could
> prevent the hub driver from processing the disconnect event. This could also
> be
> triggered by enabling debugging, which would print the -EPROTO error message
> to my slow serial console.
>
> I just realised that this debug message used to be an error before 3.19, and
> could therefore trigger the bug you're experiencing on systems with a slow
> console.
>
> Could you try updating to 3.19 (or later) or to cherry pick aa8e22128b40
> ("usb: serial: silence all non-critical read errors") and see if that helps?
>
> We should backport that one to stable either way.
>
> Thanks,
> Johan
--
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
Video transfer hangs with cx231xx deivce on ASM1042A USB 3.0 Host Controller
Hi, When connecting cx231xx video grab devices (which are USB 2.0 themselves) on ASMedia ASM1042A USB 3.0 Host Controllers the video capture process hangs after a few minutes. Besides hanging my log is flowed with the following warning: xhci_hcd :05:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? I believe it's important to notice that the same capture device on the same motherboard but on a different USB host (the USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller) runs smoothly for months (I'm using it to record real time video continuously). I tested this several months ago with the same results but didn't have the time to pursue a final proper fix. At that time I even tested enabling XHCI_TRUST_TX_LENGTH quirk for the ASM1042A USB 3.0 Host Controller which eliminated the warnings on my logs but didn't solve the hang issues. Now that I have the time I retested with the latest kernel and unfortunately the problem still exists. Here is the output of scripts/ver_linux: If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux video-teste 4.0.0-04rc7-generic #201504061936 SMP Mon Apr 6 23:37:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Gnu C scripts/ver_linux: Gnu make 4.0 scripts/ver_linux: 20: scripts/ver_linux: ld: not found binutils util-linux 2.25.1 mount debug module-init-tools 18 e2fsprogs 1.42.10 jfsutils 1.1.15 PPP2.4.5 Linux C Library2.19 Dynamic linker (ldd) 2.19 Procps 3.3.9 Net-tools 1.60 Kbd1.15.5 Sh-utils 8.23 wireless-tools 30 Modules Loaded btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c cx231xx_alsa cx25840 cx231xx videobuf_vmalloc tveeprom cx2341x rc_core videobuf_core i2c_mux v4l2_common videodev media amdkfd amd_iommu_v2 nfsd kvm_amd auth_rpcgss nfs_acl nfs kvm radeon lockd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_hdmi snd_hda_intel snd_hda_controller grace sunrpc snd_hda_codec snd_hwdep snd_pcm fscache snd_timer snd soundcore aes_x86_64 lrw ttm drm_kms_helper drm eeepc_wmi asus_wmi gf128mul glue_helper ablk_helper k10temp sparse_keymap fam15h_power video i2c_algo_bit mxm_wmi edac_core cryptd nls_iso8859_1 shpchp joydev serio_raw i2c_piix4 edac_mce_amd wmi tpm_infineon 8250_fintek mac_hid hid_generic usbhid hid psmouse ahci r8169 libahci mii I don't have a USB sniffer but I might be able to buy one it's it proofs necessary. Please let me know if there is any extra info that might help further diagnose this issue. Regards, Rodrigo Severo -- Rodrigo Severo | DIRETOR DE TECNOLOGIA Tel. +55 61 3030-1515 Siga a Fábrica no twitter:@empautaclipping fabricadeideias.com 12 ANOS DE TECNOLOGIA E COMUNICAÇÃO NUMA COMBINAÇÃO PERFEITA Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice4.00 iManufacturer 3 Linux 4.0.0-04rc7-generic ehci_hcd iProduct2 EHCI Host Controller iSerial 1 :00:16.2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 PortPwrC
Re: Video transfer hangs with cx231xx deivce on ASM1042A USB 3.0 Host Controller
On Wed, Apr 8, 2015 at 2:45 PM, Rodrigo Severo wrote: > > Please let me know if there is any extra info that might help further > diagnose this issue. Please disregard the lsusb log on my previous email as I just saw that it lacks lots of info from the cx231xx video grab device. I believe this is another result of the hanging I'm experiencing. After disconnecting and reconnecting the video grab device lsusb provides all expected info. Regards, Rodrigo -- Rodrigo Severo | DIRETOR DE TECNOLOGIA Tel. +55 61 3030-1515 Siga a Fábrica no twitter:@empautaclipping fabricadeideias.com 12 ANOS DE TECNOLOGIA E COMUNICAÇÃO NUMA COMBINAÇÃO PERFEITA Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice4.00 iManufacturer 3 Linux 4.0.0-04rc7-generic ehci_hcd iProduct2 EHCI Host Controller iSerial 1 :00:16.2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0xff Hub Port Status: Port 1: .0100 power Port 2: .0100 power Port 3: .0100 power Port 4: .0100 power Device Status: 0x0001 Self Powered Bus 011 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice4.00 iManufacturer 3 Linux 4.0.0-04rc7-generic ohci_hcd iProduct2 OHCI PCI host controller iSerial 1 :00:16.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x0012 No power switching (usb 1.0) No overcurrent protection bPwrOn2PwrGood2 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0xff Hub Port Status: Port 1: .0100 power Port 2: .0100 power Port 3: .0100 power Port 4: .0100 power Device Status: 0x0001 Self Powered Bus 010 Device 001: ID 1d6b:0001 Linux Foundation 1.1 roo
Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection
Hi Robert,
On 04/02/2015 10:13 PM, Robert Baldyga wrote:
> This patch adds VBUS pin detection support to extcon-usb-gpio driver.
> It allows to use this driver with boards which have both VBUS and ID
> pins, or only one of them.
>
> Following table of states presents relationship between this signals
> and detected cable type:
>
> State |ID | VBUS
>
> [1] USB|H|H
> [2] none |H|L
> [3] USB & USB-HOST |L|H
> [4] USB-HOST |L|L
>
> In case we have only one of these signals:
> - VBUS only - we want to distinguish between [1] and [2], so ID is always 1.
> - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
>
> Signed-off-by: Robert Baldyga
> ---
> drivers/extcon/extcon-usb-gpio.c | 169
> +++
> 1 file changed, 119 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/extcon/extcon-usb-gpio.c
> b/drivers/extcon/extcon-usb-gpio.c
> index f6aa99d..baf7add 100644
> --- a/drivers/extcon/extcon-usb-gpio.c
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -32,7 +32,9 @@ struct usb_extcon_info {
> struct extcon_dev *edev;
>
> struct gpio_desc *id_gpiod;
> + struct gpio_desc *vbus_gpiod;
> int id_irq;
> + int vbus_irq;
>
> unsigned long debounce_jiffies;
> struct delayed_work wq_detcable;
> @@ -52,40 +54,51 @@ static const char *usb_extcon_cable[] = {
> NULL,
> };
>
> +/*
> + * "USB" = VBUS and "USB-HOST" = !ID, so we have:
> + *
> + * State |ID | VBUS
> + *
> + * [1] USB|H|H
> + * [2] none |H|L
> + * [3] USB & USB-HOST |L|H
> + * [4] USB-HOST |L|L
> + *
> + * In case we have only one of these signals:
> + * - VBUS only - we want to distinguish between [1] and [2], so ID is always
> 1.
> + * - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
> + */
> +
> static void usb_extcon_detect_cable(struct work_struct *work)
> {
> int id;
> + int vbus;
> struct usb_extcon_info *info = container_of(to_delayed_work(work),
> struct usb_extcon_info,
> wq_detcable);
>
> - /* check ID and update cable state */
> - id = gpiod_get_value_cansleep(info->id_gpiod);
> - if (id) {
> - /*
> - * ID = 1 means USB HOST cable detached.
> - * As we don't have event for USB peripheral cable attached,
> - * we simulate USB peripheral attach here.
> - */
> + /* check ID and VBUS and update cable state */
> +
> + id = info->id_gpiod ?
> + gpiod_get_value_cansleep(info->id_gpiod) : 1;
> +
> + vbus = info->vbus_gpiod ?
> + gpiod_get_value_cansleep(info->vbus_gpiod) : id;
> +
> + /* at first we clean states which are no longer active */
> + if (id)
> extcon_set_cable_state(info->edev,
> -usb_extcon_cable[EXTCON_CABLE_USB_HOST],
> -false);
> + usb_extcon_cable[EXTCON_CABLE_USB_HOST], false);
> + if (!vbus)
> extcon_set_cable_state(info->edev,
> -usb_extcon_cable[EXTCON_CABLE_USB],
> -true);
> - } else {
> - /*
> - * ID = 0 means USB HOST cable attached.
> - * As we don't have event for USB peripheral cable detached,
> - * we simulate USB peripheral detach here.
> - */
> + usb_extcon_cable[EXTCON_CABLE_USB], false);
> +
> + if (!id)
> extcon_set_cable_state(info->edev,
> -usb_extcon_cable[EXTCON_CABLE_USB],
> -false);
> + usb_extcon_cable[EXTCON_CABLE_USB_HOST], true);
> + if (vbus)
> extcon_set_cable_state(info->edev,
> -usb_extcon_cable[EXTCON_CABLE_USB_HOST],
> -true);
> - }
> + usb_extcon_cable[EXTCON_CABLE_USB], true);
> }
Looks good to me of this patch.
But, I have one question about case[3]
If id is low and vbus is high, this patch will update the state of both USB and
USB-HOST cable as attached state.
Is it possible that two different cables (both USB and USB-HOST) are connected
to one port simultaneously?
> + * "USB" = VBUS and "USB-HOST" = !ID, so we have:
> + *
> + * State |ID | VBUS
> + *
> + * [1] USB|H|H
> + * [2] none |H|L
> + * [3] USB & USB-HOST |L|H
> + * [4
RE: [PATCH] usb: renesas_usbhs: Revise the binding document about the dma-names
Hi Mark,
>
> On Wed, Apr 08, 2015 at 11:42:24AM +0100, Yoshihiro Shimoda wrote:
> > Since the DT should describe the hardware (not the driver limitation),
> > This patch revises the binding document about the dma-names to change
> > simple numbering as "ch%d" instead of "tx" and "rx".
>
> The naming given in this patch looks more sensible to me.
Thank you for your comment!
> > Also this patch fixes the actual code of renesas_usbhs driver to handle
> > the new dma-names.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > This patch is based on Felipe's usb.bit / testing/next branch.
> > (commit id = bbc78c07a51f6fd29c227b1220a9016e585358ba)
>
> I take it the existing driver and binding haven't hit mainline, and
> therefore there are no users yet?
That's correct. At the moment, nobody uses the dma-names in the node of
renesas_usbhs yet.
Best regards,
Yoshihiro Shimoda
> Mark.
>
> >
> > Geert is pointed out about this issue:
> > https://www.mail-archive.com/devicetree@vger.kernel.org/msg68401.html
> >
> > .../devicetree/bindings/usb/renesas_usbhs.txt | 6 ++
> > drivers/usb/renesas_usbhs/fifo.c | 24
> > ++
> > 2 files changed, 17 insertions(+), 13 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> > index dc2a18f..ddbe304 100644
> > --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> > +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> > @@ -15,10 +15,8 @@ Optional properties:
> >- phys: phandle + phy specifier pair
> >- phy-names: must be "usb"
> >- dmas: Must contain a list of references to DMA specifiers.
> > - - dma-names : Must contain a list of DMA names:
> > - - tx0 ... tx
> > - - rx0 ... rx
> > -- This means DnFIFO in USBHS module.
> > + - dma-names : named "ch%d", where %d is the channel number ranging from
> > zero
> > +to the number of channels (DnFIFOs) minus one.
> >
> > Example:
> > usbhs: usb@e659 {
> > diff --git a/drivers/usb/renesas_usbhs/fifo.c
> > b/drivers/usb/renesas_usbhs/fifo.c
> > index 8597cf9..bc23b4a 100644
> > --- a/drivers/usb/renesas_usbhs/fifo.c
> > +++ b/drivers/usb/renesas_usbhs/fifo.c
> > @@ -1227,15 +1227,21 @@ static void usbhsf_dma_init_dt(struct device *dev,
> > struct usbhs_fifo *fifo,
> > {
> > char name[16];
> >
> > - snprintf(name, sizeof(name), "tx%d", channel);
> > - fifo->tx_chan = dma_request_slave_channel_reason(dev, name);
> > - if (IS_ERR(fifo->tx_chan))
> > - fifo->tx_chan = NULL;
> > -
> > - snprintf(name, sizeof(name), "rx%d", channel);
> > - fifo->rx_chan = dma_request_slave_channel_reason(dev, name);
> > - if (IS_ERR(fifo->rx_chan))
> > - fifo->rx_chan = NULL;
> > + /*
> > +* To avoid complex handing for DnFIFOs, the driver uses each
> > +* DnFIFO as TX or RX direction (not bi-direction).
> > +* So, the driver uses odd channels for TX, even channels for RX.
> > +*/
> > + snprintf(name, sizeof(name), "ch%d", channel);
> > + if (channel & 1) {
> > + fifo->tx_chan = dma_request_slave_channel_reason(dev, name);
> > + if (IS_ERR(fifo->tx_chan))
> > + fifo->tx_chan = NULL;
> > + } else {
> > + fifo->rx_chan = dma_request_slave_channel_reason(dev, name);
> > + if (IS_ERR(fifo->rx_chan))
> > + fifo->rx_chan = NULL;
> > + }
> > }
> >
> > static void usbhsf_dma_init(struct usbhs_priv *priv, struct usbhs_fifo
> > *fifo,
> > --
> > 1.9.1
> >
--
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/2] usb: Prefer firmware values when determining whether a port is removable
Windows appears to pay more attention to the ACPI values than any hub
configuration, so prefer the firmware's opinion on whether a port is
fixed or removable before falling back to the hub values.
Signed-off-by: Matthew Garrett
---
drivers/usb/core/hub.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d7c3d5a..ac33fdd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2350,6 +2350,23 @@ static void set_usb_port_removable(struct usb_device
*udev)
hub = usb_hub_to_struct_hub(udev->parent);
+ /*
+* If the platform firmware has provided information about a port,
+* use that to determine whether it's removable.
+*/
+ switch (hub->ports[udev->portnum - 1]->connect_type) {
+ case USB_PORT_CONNECT_TYPE_HOT_PLUG:
+ udev->removable = USB_DEVICE_REMOVABLE;
+ return;
+ case USB_PORT_CONNECT_TYPE_HARD_WIRED:
+ udev->removable = USB_DEVICE_FIXED;
+ return;
+ }
+
+ /*
+* Otherwise, check whether the hub knows whether a port is removable
+* or not
+*/
wHubCharacteristics = le16_to_cpu(hub->descriptor->wHubCharacteristics);
if (!(wHubCharacteristics & HUB_CHAR_COMPOUND))
@@ -2369,21 +2386,6 @@ static void set_usb_port_removable(struct usb_device
*udev)
else
udev->removable = USB_DEVICE_FIXED;
- /*
-* Platform firmware may have populated an alternative value for
-* removable. If the parent port has a known connect_type use
-* that instead.
-*/
- switch (hub->ports[udev->portnum - 1]->connect_type) {
- case USB_PORT_CONNECT_TYPE_HOT_PLUG:
- udev->removable = USB_DEVICE_REMOVABLE;
- break;
- case USB_PORT_CONNECT_TYPE_HARD_WIRED:
- udev->removable = USB_DEVICE_FIXED;
- break;
- default: /* use what was set above */
- break;
- }
}
/**
--
2.3.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 2/2] usb: Set unused ports to "fixed" rather than "unknown"
The Microsoft document "Using ACPI to Configure USB Ports on a Computer" makes it clear that the removable flag will be cleared on ports that are marked as unused by the firmware. Handle this case to match. Signed-off-by: Matthew Garrett --- drivers/usb/core/hub.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index ac33fdd..8166bcc 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2359,8 +2359,11 @@ static void set_usb_port_removable(struct usb_device *udev) udev->removable = USB_DEVICE_REMOVABLE; return; case USB_PORT_CONNECT_TYPE_HARD_WIRED: + case USB_PORT_NOT_USED: udev->removable = USB_DEVICE_FIXED; return; + default: + break; } /* -- 2.3.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
