[no subject]

[Offer]

-- 
-- 
Guten Tag, Wir sind eine registrierte private Geldverleiher. Wir geben
Kredite an Firmen, Einzelpersonen, die ihre finanzielle Status auf der
ganzen Welt aktualisieren müssen, mit minimalen jährlichen Zinsen von
2% .reply, wenn nötig.

Good Day, We are a registered private money lender. We give out loans
to firms, Individual who need to update their financial status all
over the world, with Minimal annual Interest Rates of 2%reply if
needed.

[no subject]

[Mavis W]

-- 

Hallo Am Mrs Mavis Wancyzk, Sie haben eine Spende von 4,800,000.00EUR Ich 
gewann die America Lottery im Wert von $ 758.7 Millionen und ich spende einen 
Teil davon an fnf glckliche Menschen und 
Wohlttigkeits-Huser in Erinnerung an meinen verstorbenen Ehemann, 
der an Krebs gestorben ist. Kontaktieren Sie mich fr weitere Details 
unter: 
[maviswanczy...@hotmail.com]

[no subject]

[Mavis Wancyzk]

-- 
Hallo Am Mrs Mavis Wancyzk, Sie haben eine Spende von 4,800,000.00EUR
Ich gewann die America Lottery im Wert von $ 758.7 Millionen und ich
spende einen Teil davon an fünf glückliche Menschen und
Wohltätigkeits-Häuser in Erinnerung an meinen verstorbenen Ehemann, der
an Krebs gestorben ist. Kontaktieren Sie mich für weitere Details unter:

[maviswanczy...@hotmail.com]

[no subject]

[Julian Lyubenov]

unsubscribe--
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

[no subject]

[Mark Henry]

Hello
My name is Gen Henry Mark, I am US military officer,i will like to get
acquainted with you, I read your profile and I really wish to indicate
my interest, please I'll be glad if you get back to me so that i can
contact you and tell you more about my self ,i wish to hear from you
soon.
Best regards,
Gen Henry Mark
--
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

[no subject]

[Mavis Wancyzk]

Hallo Am Mrs Mavis Wancyzk, Sie haben eine Spende von 4,800,000.00EUR Ich 
gewann die America Lottery im Wert von $ 758.7 Millionen und ich spende einen 
Teil davon an fünf glückliche Menschen und Wohltätigkeits-Häuser in Erinnerung 
an meinen verstorbenen Ehemann, der an Krebs gestorben ist. Kontaktieren Sie 
mich für weitere Details unter:
--
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 0/3] *** SUBJECT HERE ***

[Greg KH]

On Thu, Mar 01, 2018 at 07:08:28PM +0200, Dafna Hirschfeld wrote:
> *** BLURB HERE ***

I think you missed a subject and a blurb, and you sent it to the wrong
mailing list :(

try again?

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 0/3] *** SUBJECT HERE ***

[Dafna Hirschfeld]

*** BLURB HERE ***

Dafna Hirschfeld (3):
  staging: rtl8192e: Fix issues regarding blank lines
  staging: rtl8192e: Remove unnecessary parentheses
  staging: rtl8192e: Add spaces around operators.

 drivers/staging/rtl8192e/rtl8192e/rtl_wx.c | 51 +++---
 1 file changed, 12 insertions(+), 39 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

[no subject]

[Chris Murphy]

subscribe linux-usb
--
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

[no subject]

[Jones]

This is in regards to an inheritance on your surname, reply back using your 
email address, stating your full name for more details. Reply to email for 
info. Email me here ( ger...@dr.com )
--
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

[no subject]

[Sally Davidson]

-- 
Guten Tag:
Sind Sie in finanziellen Schwierigkeiten? Benötigen Sie ein Darlehen
mit niedrigem Zinssatz? Wenn ja, kontaktieren Sie uns jetzt mit
Ihr Name:
Land:
Darlehensbetrag:
Telefonnummer:
Darlehens Dauer:
Staat:
Sex:
Beruf:
Monatliches Einkommen:
Alter:
Privatadresse:
--
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

[no subject]

[Davidson Sally]

-- 
Guten Tag:
Sind Sie in finanziellen Schwierigkeiten? Benötigen Sie ein Darlehen
mit niedrigem Zinssatz? Wenn ja, kontaktieren Sie uns jetzt mit
Ihr Name:
Land:
Darlehensbetrag:
Telefonnummer:
Darlehens Dauer:
Staat:
Sex:
Beruf:
Monatliches Einkommen:
Alter:
Privatadresse:
--
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] Subject: [PATCH] usb:dwc3:fix access poisoned list_head in dwc3_gadget_giveback

[Yu Chen]

From: Yu Chen 

Unable to handle kernel paging request at virtual address dead0108
pgd = fff7a3179000
[dead0108] *pgd=230e0003, *pud=230e0003,
*pmd=
Internal error: Oops: 9644 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 1 Comm: init Tainted: GW   4.4.23+ #1
TGID: 1 Comm: init
Hardware name: kirin970 (DT)
task: fff99f19 ti: fff99f1740e0 task.ti: fff99f1740e0
PC is at dwc3_gadget_giveback+0xa8/0x228
LR is at dwc3_remove_requests+0x44/0x88

The crash occurred when usb work as rndis device and
__dwc3_gadget_kick_transfer return error in __dwc3_gadget_ep_queue.
The request submited in __dwc3_gadget_ep_queue is moved to started_list
but not kicked. It is stil on started_list although
__dwc3_gadget_kick_transfer failed. When dwc3_gadget_ep_queue return
error to u_ether driver, the request will be resubmit to dwc3 driver.
At last, the same request is both on started_list and pending_list,
it will be list_del twice in dwc3_remove_requests and cause crash.

Signed-off-by: Yu Chen 
---
 drivers/usb/dwc3/gadget.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 639dd1b163a0..a913e64ca4e0 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1278,9 +1278,28 @@ static void dwc3_gadget_start_isoc(struct dwc3 *dwc,
__dwc3_gadget_start_isoc(dwc, dep, cur_uf);
 }
 
+static int dwc3_gadget_is_req_pengding_or_started(struct dwc3_ep *dep,
+   struct dwc3_request *req)
+{
+   struct dwc3_request *iterate_req;
+
+   list_for_each_entry(iterate_req, >pending_list, list) {
+   if (iterate_req == req)
+   return 1;
+   }
+
+   list_for_each_entry(iterate_req, >started_list, list) {
+   if (iterate_req == req)
+   return 1;
+   }
+
+   return 0;
+}
+
 static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request 
*req)
 {
struct dwc3 *dwc = dep->dwc;
+   int ret;
 
if (!dep->endpoint.desc) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
@@ -1334,7 +1353,14 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
}
 
 out:
-   return __dwc3_gadget_kick_transfer(dep);
+   ret = __dwc3_gadget_kick_transfer(dep);
+   if (ret && dwc3_gadget_is_req_pengding_or_started(dep, req)) {
+   dev_dbg(dwc->dev, "%s: req still on list, return 0\n",
+   dep->name);
+   ret = 0;
+   }
+
+   return ret;
 }
 
 static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
-- 
2.15.0-rc2

--
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

[no subject]

[Alexander Kappner]

Date: Wed, 6 Dec 2017 15:28:37 -0800
Subject: [PATCH] usb-core: Fix potential null pointer dereference in 
xhci-debugfs.c

My kernel crashed just after resuming from hibernate and starting usbmuxd
(a user-space daemon for iOS device pairing) with several USB devices
connected (dmesg attached).

Backtrace leads to:

0x8170465d is in xhci_debugfs_create_endpoint
(drivers/usb/host/xhci-debugfs.c:381).
376   int ep_index)
377 {
378 struct xhci_ep_priv *epriv;
379 struct xhci_slot_priv   *spriv = dev->debugfs_private;
380
381 if (spriv->eps[ep_index])
382 return;
383
384 epriv = kzalloc(sizeof(*epriv), GFP_KERNEL);
385 if (!epriv)

The read violation happens at address 0x40 and sizeof(struct
xhci_ep_priv)=0x40, so it seems ep_index is 1 and spriv is NULL here.

spriv gets allocated in xhci_debugfs_create_slot:

...
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return;
...

There's no separate error path if this allocation fails, so we might be
left with NULL in priv. Subsequent users of priv thus need to check for
this NULL - so this is what the patch does.

There might be other ways of triggering this null pointer dereference,
including when xhci_resume frees the device structures (e.g. after
returning from a hibernate), but I wasn't able to find or reproduce it. 

[63953.758083] BUG: unable to handle kernel NULL pointer dereference at
0040
[63953.758090] IP: xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758091] PGD bb911d067 P4D bb911d067 PUD 10500ff067 PMD 0
[63953.758093] Oops:  [#1] PREEMPT SMP
[63953.758094] Modules linked in: ipheth tun nvidia_modeset(PO) iwlmvm
mac80211 iwlwifi nvidia(PO) btusb btrtl btbcm btintel bluetooth cfg80211
qmi_wwan ecdh_generic thinkpad_acpi rfkill
[63953.758103] CPU: 4 PID: 27091 Comm: usbmuxd Tainted: P   O
4.14.0.1-12769-g1deab8c #1
[63953.758104] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W
(1.35 ) 11/10/2016
[63953.758105] task: 8810527ba0c0 task.stack: c9000a8ec000
[63953.758107] RIP: 0010:xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758108] RSP: 0018:c9000a8efc80 EFLAGS: 00010206
[63953.758109] RAX:  RBX: 88105a71c000 RCX:
0003
[63953.758110] RDX: 0003 RSI: 880c0b57e000 RDI:
88105a71c238
[63953.758110] RBP: 0003 R08: 881063800600 R09:
0003
[63953.758111] R10: 88105a71c238 R11: 0001 R12:
0011
[63953.758112] R13: 0018 R14:  R15:

[63953.758113] FS:  7f0a77715700() GS:8810a3d0()
knlGS:
[63953.758114] CS:  0010 DS:  ES:  CR0: 80050033
[63953.758115] CR2: 0040 CR3: 0003f91a8006 CR4:
003606e0
[63953.758115] DR0:  DR1:  DR2:

[63953.758116] DR3:  DR6: fffe0ff0 DR7:
0400
[63953.758117] Call Trace:
[63953.758120]  xhci_add_endpoint+0x127/0x2b0
[63953.758123]  usb_hcd_alloc_bandwidth+0x1ad/0x300
[63953.758125]  usb_set_configuration+0x1c8/0x880
[63953.758128]  usbdev_do_ioctl+0xc41/0x1120
[63953.758130]  usbdev_ioctl+0xa/0x10
[63953.758151]  do_vfs_ioctl+0x8b/0x5c0
[63953.758153]  ? __fget+0x6c/0xb0
[63953.758155]  SyS_ioctl+0x76/0x90
[63953.758157]  do_syscall_64+0x6b/0x290
[63953.758173]  entry_SYSCALL64_slow_path+0x25/0x25
[63953.758175] RIP: 0033:0x7f0a76a151c7
[63953.758175] RSP: 002b:7ffd1431b0c8 EFLAGS: 0202 ORIG_RAX:
0010
[63953.758177] RAX: ffda RBX: 023239a0 RCX:
7f0a76a151c7
[63953.758178] RDX: 7ffd1431b0dc RSI: 80045505 RDI:
000e
[63953.758178] RBP: 023240c0 R08: 7ffd1431b008 R09:
0004
[63953.758179] R10: 7ffd1431aec0 R11: 0202 R12:
023240c0
[63953.758180] R13: 0001 R14: 0056 R15:
0038
[63953.758182] Code: e9 39 ff ff ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00
00 41 57 41 56 41 55 41 54 55 48 63 ea 53 4c 8b b6 88 15 00 00 4d 8d 2c ee
<49> 83 7d 28 00 74 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 3d
[63953.758202] RIP: xhci_debugfs_create_endpoint+0x1d/0xa0 RSP:
c9000a8efc80
[63953.758203] CR2: 0040
[63953.758204] ---[ end trace 1f7ea9a959f02054 ]---

Signed-off-by: Alexander Kappner <a...@godking.net>
---
 drivers/usb/host/xhci-debugfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
index 4f7895d..1cea59c 100644
--- a/drivers/usb/host/xhci-debugfs.c
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -378,6 +378,9 @@ void xhci_debugfs_create_endpoint(struct xhci_hcd *xhci,
struct xhci_ep_priv *epriv;
struct xhci_slot_priv   *spriv = dev->debugfs_private;
 
+   if (!spriv)
+   return;
+
 

[no subject]

[Friedrich Mayrhofer]

This is the second time i am sending you this Email.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me  
personally for more details.


Regards.
Friedrich Mayrhofer






This message was sent using IMP, the Internet Messaging Program.

--
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

[no subject]

[Roy Cockrum Foundation]

Hallo, Sie machen eine Spende von 4.800.000,00 EUR, ich habe die America Lotto 
in Amerika im Wert von 259,9 Millionen Dollar gewonnen, und ich gebe einen Teil 
davon fünf glückliche Menschen und Wohltätigkeits-Häuser in Erinnerung an meine 
verstorbene Frau, die an Krebs gestorben ist. Kontaktieren Sie mich für weitere 
Informationen: roycockrum2...@gmail.com
--
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

[no subject]

[Manish Lachwani]

hi Linux

http://bit.ly/2yfmtQy


Best Wishes

Manish Lachwani
--
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

[no subject]

[prabhu kalyan]

unsubscripted
--
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

[no subject]

[Finanzdienstleistungen Pvt Ltd]

Brauchen Sie ein persnliches oder geschftliches Darlehen ohne 
Stress und schnelle Genehmigung? Wenn ja, kontaktieren Sie uns heute, da wir 
derzeit Darlehen zu einem hervorragenden Zinssatz anbieten. Unser Darlehen ist 
gesichert und sicher, unsere Kunden Glck ist unsere Strke. Fr 
weitere Informationen und Bewerbung
--
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

[no subject]

[Youichi Kanno]

Sir/Madam

I am sorry to encroach into your privacy in this manner, I found you  
listed in the Trade Center Chambers of Commerce directory here in  
Japan, My name is Youichi Kanno and I work in Audit & credit  
Supervisory role at The Norinchukin Bank, I need your assistance to  
process the fund claims oF $18,100,000.00 (Eighteen Million, One  
Hundred Thousand, USD) of a deceased client Mr. Grigor Kassan, And i  
need your assistance to process the fund claims, I only pray at this  
time that your address is still valid. I want to solicit your  
attention to receive this money on my behalf. The purpose of my  
contacting you is because my status would not permit me to do this  
alone.


I hope to hear from you soon so we can discuss the logistic of moving  
the funds to a safe offshore bank.


Yours sincerely,
Youichi Kanno
Phone Number: +81345400962





--
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: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001
From: Ajay Kaher <ajay.ka...@samsung.com>
Date: Thu, 9 Mar 2017 16:07:54 +0530
Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two
 USB class drivers try to call init_usb_class simultaneously

There is race condition when two USB class drivers try to call
init_usb_class at the same time and leads to crash.
code path: probe->usb_register_dev->init_usb_class
 
To solve this, mutex locking has been added in init_usb_class() and 
destroy_usb_class().

As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
because usb_class can never be NULL there.

Signed-off-by: Ajay Kaher <ajay.ka...@samsung.com>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---
 drivers/usb/core/file.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..422ce7b 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);

 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)

 static void destroy_usb_class(void)
 {
- if (usb_class)
-  kref_put(_class->kref, release_usb_class);
+ mutex_lock(_usb_class_mutex);
+ kref_put(_class->kref, release_usb_class);
+ mutex_unlock(_usb_class_mutex);
 }

 int usb_major_init(void)
@@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
  if (intf->minor >= 0)
   return -EADDRINUSE;

+ mutex_lock(_usb_class_mutex);
  retval = init_usb_class();
+ mutex_unlock(_usb_class_mutex);
+
  if (retval)
   return retval;

--
1.7.9.5

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Thu, Mar 09, 2017 at 11:34:25AM +, Ajay Kaher wrote:
> From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001
> From: Ajay Kaher <ajay.ka...@samsung.com>
> Date: Thu, 9 Mar 2017 16:07:54 +0530
> Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when 
> two
>  USB class drivers try to call init_usb_class simultaneously

Why is your subject line have the word "subject" in it?

Please fix your email client so you don't have the whole git commit
header in the body of the email like you do here.

Also, no need to say "Core:" or "BugFix:"

> 
> There is race condition when two USB class drivers try to call
> init_usb_class at the same time and leads to crash.
> code path: probe->usb_register_dev->init_usb_class
>  
> To solve this, mutex locking has been added in init_usb_class() and 
> destroy_usb_class().
> 
> As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
> because usb_class can never be NULL there.
> 
> Signed-off-by: Ajay Kaher <ajay.ka...@samsung.com>
> Acked-by: Alan Stern <st...@rowland.harvard.edu>
> ---
>  drivers/usb/core/file.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..422ce7b 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)
> 
>  static void destroy_usb_class(void)
>  {
> - if (usb_class)
> -  kref_put(_class->kref, release_usb_class);
> + mutex_lock(_usb_class_mutex);
> + kref_put(_class->kref, release_usb_class);
> + mutex_unlock(_usb_class_mutex);
>  }
> 
>  int usb_major_init(void)
> @@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
>   if (intf->minor >= 0)
>return -EADDRINUSE;
> 
> + mutex_lock(_usb_class_mutex);
>   retval = init_usb_class();
> + mutex_unlock(_usb_class_mutex);
> +
>   if (retval)
>return retval;
> 

All tabs were turned into spaces and this patch can not be applied :(

Please fix up and try again.  Send a patch to yourself first to see if
it works properly before sending it to us.

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

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Tue, Mar 07, 2017 at 04:35:37AM +, Ajay Kaher wrote:
>  
>  
>  
> > On Fri, 3 Mar 2017, Ajay Kaher wrote:
> > 
> > > > usb_class->kref is not accessible outside the file.c
> > > > as usb_class is _static_ inside the file.c and
> > > > pointer of usb_class->kref is not passed anywhere.
> > > > 
> > > > Hence as you wanted, there are no references of usb_class->kref
> > > > other than taken by init_usb_class() and released by 
> > >destroy_usb_class().
> > > 
> > > Verified the code again, I hope my last comments clarifed the things
> > > which came in your mind and helps you to accept the patch :)
> >  
> > Your main point is that usb_class->kref is accessed from only two
> > points, both of which are protected by the new mutex.  This means there
> > is no reason for the value to be a struct kref at all.  You should
> > change it to an int (and change its name).  Leaving it as a kref will
> > make readers wonder why it needs to be updated atomically.
> 
> At many places in Linux kernel, instances of Kref have been used within
> Mutex, SpinLock and don’t have any side effect.
> 
> Making to int and handle (i.e. get/put) it within file.c seems
> not good as we have Kref. Instead, we can have non_atomic version of kref.
> We can discuss about non_atomic kref in another thread, if you are interested.
> 
> > Also, why does destroy_usb_class() have that "if (usb_class) "test? 
> > Isn't it true that usb_class can never be NULL there?
> 
> Removed in Patch v4.
> 
> thanks,
> ajay kaher
>  
>   
> Signed-off-by: Ajay Kaher
>  

Can you resend this in a format that I can apply it in?  I suggest
reading Documentation/SubmittingPatches.  If you have any questions
about the correct format, please let me know.

Also add Alan's ack to it.

thanks,

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

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Alan Stern]

On Tue, 7 Mar 2017, Ajay Kaher wrote:

> > On Fri, 3 Mar 2017, Ajay Kaher wrote:
> > 
> > > > usb_class->kref is not accessible outside the file.c
> > > > as usb_class is _static_ inside the file.c and
> > > > pointer of usb_class->kref is not passed anywhere.
> > > > 
> > > > Hence as you wanted, there are no references of usb_class->kref
> > > > other than taken by init_usb_class() and released by 
> > >destroy_usb_class().
> > > 
> > > Verified the code again, I hope my last comments clarifed the things
> > > which came in your mind and helps you to accept the patch :)
> >  
> > Your main point is that usb_class->kref is accessed from only two
> > points, both of which are protected by the new mutex.  This means there
> > is no reason for the value to be a struct kref at all.  You should
> > change it to an int (and change its name).  Leaving it as a kref will
> > make readers wonder why it needs to be updated atomically.
> 
> At many places in Linux kernel, instances of Kref have been used within
> Mutex, SpinLock and don’t have any side effect.
> 
> Making to int and handle (i.e. get/put) it within file.c seems
> not good as we have Kref. Instead, we can have non_atomic version of kref.
> We can discuss about non_atomic kref in another thread, if you are interested.

Okay.

> > Also, why does destroy_usb_class() have that "if (usb_class) "test? 
> > Isn't it true that usb_class can never be NULL there?
> 
> Removed in Patch v4.
> 
> thanks,
> ajay kaher
>  
>   
> Signed-off-by: Ajay Kaher
>  
> ---
> 
>  drivers/usb/core/file.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..422ce7b 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)
> 
>  static void destroy_usb_class(void)
>  {
> -   if (usb_class)
> -   kref_put(_class->kref, release_usb_class);
> +   mutex_lock(_usb_class_mutex);
> +   kref_put(_class->kref, release_usb_class);
> +   mutex_unlock(_usb_class_mutex);
>  }
> 
>  int usb_major_init(void)
> @@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
> 
> +   mutex_lock(_usb_class_mutex);
> retval = init_usb_class();
> +   mutex_unlock(_usb_class_mutex);
> +
> if (retval)
> return retval;

Acked-by: Alan Stern 

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: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

 
 
 
> On Fri, 3 Mar 2017, Ajay Kaher wrote:
> 
> > > usb_class->kref is not accessible outside the file.c
> > > as usb_class is _static_ inside the file.c and
> > > pointer of usb_class->kref is not passed anywhere.
> > > 
> > > Hence as you wanted, there are no references of usb_class->kref
> > > other than taken by init_usb_class() and released by destroy_usb_class().
> > 
> > Verified the code again, I hope my last comments clarifed the things
> > which came in your mind and helps you to accept the patch :)
>  
> Your main point is that usb_class->kref is accessed from only two
> points, both of which are protected by the new mutex.  This means there
> is no reason for the value to be a struct kref at all.  You should
> change it to an int (and change its name).  Leaving it as a kref will
> make readers wonder why it needs to be updated atomically.

At many places in Linux kernel, instances of Kref have been used within
Mutex, SpinLock and don’t have any side effect.

Making to int and handle (i.e. get/put) it within file.c seems
not good as we have Kref. Instead, we can have non_atomic version of kref.
We can discuss about non_atomic kref in another thread, if you are interested.

> Also, why does destroy_usb_class() have that "if (usb_class) "test? 
> Isn't it true that usb_class can never be NULL there?

Removed in Patch v4.

thanks,
ajay kaher
 
  
Signed-off-by: Ajay Kaher
 
---

 drivers/usb/core/file.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..422ce7b 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);

 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)

 static void destroy_usb_class(void)
 {
-   if (usb_class)
-   kref_put(_class->kref, release_usb_class);
+   mutex_lock(_usb_class_mutex);
+   kref_put(_class->kref, release_usb_class);
+   mutex_unlock(_usb_class_mutex);
 }

 int usb_major_init(void)
@@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
if (intf->minor >= 0)
return -EADDRINUSE;

+   mutex_lock(_usb_class_mutex);
retval = init_usb_class();
+   mutex_unlock(_usb_class_mutex);
+
if (retval)
return retval;

Re: FW: FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Alan Stern]

On Fri, 3 Mar 2017, Ajay Kaher wrote:

> > usb_class->kref is not accessible outside the file.c
> > as usb_class is _static_ inside the file.c and
> > pointer of usb_class->kref is not passed anywhere.
> > 
> > Hence as you wanted, there are no references of usb_class->kref
> > other than taken by init_usb_class() and released by destroy_usb_class().
> 
> Verified the code again, I hope my last comments clarifed the things
> which came in your mind and helps you to accept the patch :)

Your main point is that usb_class->kref is accessed from only two
points, both of which are protected by the new mutex.  This means there
is no reason for the value to be a struct kref at all.  You should
change it to an int (and change its name).  Leaving it as a kref will
make readers wonder why it needs to be updated atomically.

Also, why does destroy_usb_class() have that "if (usb_class) "test?  
Isn't it true that usb_class can never be NULL there?

Alan Stern

> thanks,
> ajay kaher
>  
>  
> Signed-off-by: Ajay Kaher
>  
> ---
>  
>  drivers/usb/core/file.c |6 ++
>  1 file changed, 6 insertions(+)
>  
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..a12d184 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
>  
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)
>  
>  static void destroy_usb_class(void)
>  {
> +   mutex_lock(_usb_class_mutex);
> if (usb_class)
> kref_put(_class->kref, release_usb_class);
> +   mutex_unlock(_usb_class_mutex);
>  }
>  
>  int usb_major_init(void)
> @@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
>  
> +   mutex_lock(_usb_class_mutex);
> retval = init_usb_class();
> +   mutex_unlock(_usb_class_mutex);
> +
> if (retval)
> return retval;
> 

--
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

FW: FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

> On Thr, 2 Mar 2017, Ajay Kaher wrote:
>> On Wed, 1 Mar 2017, Alan Stern wrote:
>>> On Wed, 1 Mar 2017, Ajay Kaher wrote:
 On Mon, 22 Feb 2017, Ajay Kaher wrote:
 
> 
>> Alan, as per my understanding I have shifted the lock from
>> release_usb_class() to destroy_usb_class() in patch v3. 
>> If it is not right, please explain in detail which race condition
>> I have missed and also share your suggestions.
>> 
> 
> Have you considered what would happen if destroy_usb_class() ran, but 
> some other CPU was still holding a reference to usb_class?  And what if 
> the last reference gets dropped later on, while init_usb_class() is 
> running?
 
 Access of usb_class->kref is only from either init_usb_class()
 or destroy_usb_class(), and both these functions are now protected
 with Mutex Locking in patch v3, so there is no chance of race condition
 as per above scenarios.
 
> Maybe that's not possible here, but it is possible in general for 
> refcounted objects.  So yes, this code is probably okay, but it isn't 
> good form.
 
 As per my understanding, I found to be one of the best possible solution
 for this problem and this solutiuon don't have any side effect.
>>> 
>>> Alan, I had shared modified Patch v3 as per your inputs to prevent
>>> the race condition during simultaneously calling of init_usb_class().
>>> If you think there is scope to improve the patch, please share your inputs.
>> 
>> Under the circumstances, your patch is acceptable.
>> 
>> If you really want to make the point crystal clear, you could replace 
>> usb_class->kref with an ordinary integer counter.  Then it would be 
>> obvious that there are no references other than the ones taken by 
>> init_usb_class() and released by destroy_usb_class().
> 
> usb_class->kref is not accessible outside the file.c
> as usb_class is _static_ inside the file.c and
> pointer of usb_class->kref is not passed anywhere.
> 
> Hence as you wanted, there are no references of usb_class->kref
> other than taken by init_usb_class() and released by destroy_usb_class().

Verified the code again, I hope my last comments clarifed the things
which came in your mind and helps you to accept the patch :)
 
thanks,
ajay kaher
 
 
Signed-off-by: Ajay Kaher
 
---
 
 drivers/usb/core/file.c |6 ++
 1 file changed, 6 insertions(+)
 
diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..a12d184 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);
 
 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)
 
 static void destroy_usb_class(void)
 {
+   mutex_lock(_usb_class_mutex);
if (usb_class)
kref_put(_class->kref, release_usb_class);
+   mutex_unlock(_usb_class_mutex);
 }
 
 int usb_major_init(void)
@@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
if (intf->minor >= 0)
return -EADDRINUSE;
 
+   mutex_lock(_usb_class_mutex);
retval = init_usb_class();
+   mutex_unlock(_usb_class_mutex);
+
if (retval)
return retval;

FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

> On Wed, 1 Mar 2017, Alan Stern wrote:
>> On Wed, 1 Mar 2017, Ajay Kaher wrote:
>>> On Mon, 22 Feb 2017, Ajay Kaher wrote:
>>> 
 
> Alan, as per my understanding I have shifted the lock from
> release_usb_class() to destroy_usb_class() in patch v3. 
> If it is not right, please explain in detail which race condition
> I have missed and also share your suggestions.
> 
 
 Have you considered what would happen if destroy_usb_class() ran, but 
 some other CPU was still holding a reference to usb_class?  And what if 
 the last reference gets dropped later on, while init_usb_class() is 
 running?
>>> 
>>> Access of usb_class->kref is only from either init_usb_class()
>>> or destroy_usb_class(), and both these functions are now protected
>>> with Mutex Locking in patch v3, so there is no chance of race condition
>>> as per above scenarios.
>>> 
 Maybe that's not possible here, but it is possible in general for 
 refcounted objects.  So yes, this code is probably okay, but it isn't 
 good form.
>>> 
>>> As per my understanding, I found to be one of the best possible solution
>>> for this problem and this solutiuon don't have any side effect.
>> 
>> Alan, I had shared modified Patch v3 as per your inputs to prevent
>> the race condition during simultaneously calling of init_usb_class().
>> If you think there is scope to improve the patch, please share your inputs.
> 
> Under the circumstances, your patch is acceptable.
> 
> If you really want to make the point crystal clear, you could replace 
> usb_class->kref with an ordinary integer counter.  Then it would be 
> obvious that there are no references other than the ones taken by 
> init_usb_class() and released by destroy_usb_class().
 
usb_class->kref is not accessible outside the file.c
as usb_class is _static_ inside the file.c and
pointer of usb_class->kref is not passed anywhere.

Hence as you wanted, there are no references of usb_class->kref
other than taken by init_usb_class() and released by destroy_usb_class().

 
thanks,
ajay kaher
 
 
Signed-off-by: Ajay Kaher
 
---
 
 drivers/usb/core/file.c |6 ++
 1 file changed, 6 insertions(+)
 
diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..a12d184 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);
 
 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)
 
 static void destroy_usb_class(void)
 {
+   mutex_lock(_usb_class_mutex);
if (usb_class)
kref_put(_class->kref, release_usb_class);
+   mutex_unlock(_usb_class_mutex);
 }
 
 int usb_major_init(void)
@@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
if (intf->minor >= 0)
return -EADDRINUSE;
 
+   mutex_lock(_usb_class_mutex);
retval = init_usb_class();
+   mutex_unlock(_usb_class_mutex);
+
if (retval)
return retval;
 
 
 
Thanks and Regards,
Ajay Kaher

Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Alan Stern]

On Wed, 1 Mar 2017, Ajay Kaher wrote:

> > On Mon, 22 Feb 2017, Ajay Kaher wrote:
> > 
> >> On Mon, 20 Feb 2017, Ajay Kaher wrote:
> >> 
> >>> Alan, as per my understanding I have shifted the lock from
> >>> release_usb_class() to destroy_usb_class() in patch v3. 
> >>> If it is not right, please explain in detail which race condition
> >>> I have missed and also share your suggestions.
> >>> 
> >> 
> >> Have you considered what would happen if destroy_usb_class() ran, but 
> >> some other CPU was still holding a reference to usb_class?  And what if 
> >> the last reference gets dropped later on, while init_usb_class() is 
> >> running?
> > 
> > Access of usb_class->kref is only from either init_usb_class()
> > or destroy_usb_class(), and both these functions are now protected
> > with Mutex Locking in patch v3, so there is no chance of race condition
> > as per above scenarios.
> > 
> >> Maybe that's not possible here, but it is possible in general for 
> >> refcounted objects.  So yes, this code is probably okay, but it isn't 
> >> good form.
> > 
> > As per my understanding, I found to be one of the best possible solution
> > for this problem and this solutiuon don't have any side effect.
> 
> Alan, I had shared modified Patch v3 as per your inputs to prevent
> the race condition during simultaneously calling of init_usb_class().
> If you think there is scope to improve the patch, please share your inputs.

Under the circumstances, your patch is acceptable.

If you really want to make the point crystal clear, you could replace 
usb_class->kref with an ordinary integer counter.  Then it would be 
obvious that there are no references other than the ones taken by 
init_usb_class() and released by destroy_usb_class().

Alan Stern

> thanks,
> ajay kaher
> 
> 
> Signed-off-by: Ajay Kaher
> 
> ---
> 
>  drivers/usb/core/file.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..a12d184 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)
> 
>  static void destroy_usb_class(void)
>  {
> +   mutex_lock(_usb_class_mutex);
> if (usb_class)
> kref_put(_class->kref, release_usb_class);
> +   mutex_unlock(_usb_class_mutex);
>  }
> 
>  int usb_major_init(void)
> @@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
> 
> +   mutex_lock(_usb_class_mutex);
> retval = init_usb_class();
> +   mutex_unlock(_usb_class_mutex);
> +
> if (retval)
> return retval;
> 
>  
> 

--
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

FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

> On Mon, 22 Feb 2017, Ajay Kaher wrote:
> 
>> On Mon, 20 Feb 2017, Ajay Kaher wrote:
>> 
>>> Alan, as per my understanding I have shifted the lock from
>>> release_usb_class() to destroy_usb_class() in patch v3. 
>>> If it is not right, please explain in detail which race condition
>>> I have missed and also share your suggestions.
>>> 
>> 
>> Have you considered what would happen if destroy_usb_class() ran, but 
>> some other CPU was still holding a reference to usb_class?  And what if 
>> the last reference gets dropped later on, while init_usb_class() is 
>> running?
> 
> Access of usb_class->kref is only from either init_usb_class()
> or destroy_usb_class(), and both these functions are now protected
> with Mutex Locking in patch v3, so there is no chance of race condition
> as per above scenarios.
> 
>> Maybe that's not possible here, but it is possible in general for 
>> refcounted objects.  So yes, this code is probably okay, but it isn't 
>> good form.
> 
> As per my understanding, I found to be one of the best possible solution
> for this problem and this solutiuon don't have any side effect.

Alan, I had shared modified Patch v3 as per your inputs to prevent
the race condition during simultaneously calling of init_usb_class().
If you think there is scope to improve the patch, please share your inputs.

thanks,
ajay kaher


Signed-off-by: Ajay Kaher

---

 drivers/usb/core/file.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..a12d184 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);

 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)

 static void destroy_usb_class(void)
 {
+   mutex_lock(_usb_class_mutex);
if (usb_class)
kref_put(_class->kref, release_usb_class);
+   mutex_unlock(_usb_class_mutex);
 }

 int usb_major_init(void)
@@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
if (intf->minor >= 0)
return -EADDRINUSE;

+   mutex_lock(_usb_class_mutex);
retval = init_usb_class();
+   mutex_unlock(_usb_class_mutex);
+
if (retval)
return retval;

 

RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

On Tue, 21 Feb 2017, Alan Stern wrote: 
 
> On Mon, 20 Feb 2017, Ajay Kaher wrote:
 
>> Alan, as per my understanding I have shifted the lock from
>> release_usb_class() to destroy_usb_class() in patch v3. 
>> If it is not right, please explain in detail which race condition
>> I have missed and also share your suggestions.
>> 
> 
> Have you considered what would happen if destroy_usb_class() ran, but 
> some other CPU was still holding a reference to usb_class?  And what if 
> the last reference gets dropped later on, while init_usb_class() is 
> running?

Access of usb_class->kref is only from either init_usb_class()
or destroy_usb_class(), and both these functions are now protected
with Mutex Locking in patch v3, so there is no chance of race condition
as per above scenarios.

> Maybe that's not possible here, but it is possible in general for 
> refcounted objects.  So yes, this code is probably okay, but it isn't 
> good form.
 
As per my understanding, I found to be one of the best possible solution
for this problem and this solutiuon don't have any side effect.

thanks,
ajay kaher
 
 
> Signed-off-by: Ajay Kaher
> 
> ---
> 
>  drivers/usb/core/file.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..a12d184 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)
> 
>  static void destroy_usb_class(void)
>  {
> +   mutex_lock(_usb_class_mutex);
> if (usb_class)
> kref_put(_class->kref, release_usb_class);
> +   mutex_unlock(_usb_class_mutex);
>  }
> 
>  int usb_major_init(void)
> @@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
> 
> +   mutex_lock(_usb_class_mutex);
> retval = init_usb_class();
> +   mutex_unlock(_usb_class_mutex);
> +
> if (retval)
> return retval;
 
 
 
 
 
 
 

Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Alan Stern]

On Mon, 20 Feb 2017, Ajay Kaher wrote:

> Alan, as per my understanding I have shifted the lock from
> release_usb_class() to destroy_usb_class() in patch v3. 
> If it is not right, please explain in detail which race condition
> I have missed and also share your suggestions.
> 
> thanks,
> ajay kaher
> 
> Signed-off-by: Ajay Kaher
> 
> ---
> 
>  drivers/usb/core/file.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..a12d184 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)
> 
>  static void destroy_usb_class(void)
>  {
> +   mutex_lock(_usb_class_mutex);
> if (usb_class)
> kref_put(_class->kref, release_usb_class);
> +   mutex_unlock(_usb_class_mutex);
>  }
> 
>  int usb_major_init(void)
> @@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
> 
> +   mutex_lock(_usb_class_mutex);
> retval = init_usb_class();
> +   mutex_unlock(_usb_class_mutex);
> +
> if (retval)
> return retval;

Have you considered what would happen if destroy_usb_class() ran, but 
some other CPU was still holding a reference to usb_class?  And what if 
the last reference gets dropped later on, while init_usb_class() is 
running?

Maybe that's not possible here, but it is possible in general for 
refcounted objects.  So yes, this code is probably okay, but it isn't 
good form.

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: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

 
On Thu, 16 Feb 2017, Alan Stern wrote: 

> On Thu, 16 Feb 2017, Ajay Kaher wrote:
> 
>> > On Thu, 14 Feb 2017, Alan Stern wrote:
>> > 
>> > I think Ajay's argument is correct and a patch is needed.  But this
>> > patch misses the race between init_usb_class() and release_usb_class().  
>> 
>> Thanks Alan for your comments, in patch v2 I have taken care for
>> release_usb_class() also. Please review again.
>> 
>> > The basic problem is that reference counting doesn't work when you try
>> > to use the same global pointer (usb_class) to refer to multiple
>> > generations of a dynamically allocated entity.  We had the same sort of
>> > problem many years ago with the usb_interface structure (and we
>> > ultimately fixed it by creating a separate usb_interface_cache
>> > structure).
>> >  
>> > The best approach here would be to forget about all the reference
>> > counting.  Get rid of usb_class entirely, and create the "usbmisc"
>> > class structure just once, when usbcore initializes.  Or, if you
>> > prefer, use a mutex to protect a routine that allocates the class
>> > structure dynamically, just once.  Either way, don't deallocate it
>> > until usbcore is unloaded.
>> 
>> usbmisc class creation should not require everytime when USB core
>> initializes. So better to keep usbmisc class creation as it is. 
>> And to prevent the race conditions just protect it with Mutex locking
>> as per patch v2.
> 
> This is not right.  What happens if usb_register_dev() runs just before
> release_usb_class() calls mutex_lock()?
 
Alan, as per my understanding I have shifted the lock from
release_usb_class() to destroy_usb_class() in patch v3. 
If it is not right, please explain in detail which race condition
I have missed and also share your suggestions.

thanks,
ajay kaher

Signed-off-by: Ajay Kaher

---

 drivers/usb/core/file.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..a12d184 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);

 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)

 static void destroy_usb_class(void)
 {
+   mutex_lock(_usb_class_mutex);
if (usb_class)
kref_put(_class->kref, release_usb_class);
+   mutex_unlock(_usb_class_mutex);
 }

 int usb_major_init(void)
@@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
if (intf->minor >= 0)
return -EADDRINUSE;

+   mutex_lock(_usb_class_mutex);
retval = init_usb_class();
+   mutex_unlock(_usb_class_mutex);
+
if (retval)
return retval;







 

RE: RE: Re: Re: Re: Subject: [PATCH v2] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Alan Stern]

On Thu, 16 Feb 2017, Ajay Kaher wrote:

> > On Thu, 14 Feb 2017, Alan Stern wrote:
> > 
> > I think Ajay's argument is correct and a patch is needed.  But this
> > patch misses the race between init_usb_class() and release_usb_class().  
> 
> Thanks Alan for your comments, in patch v2 I have taken care for
> release_usb_class() also. Please review again.
> 
> > The basic problem is that reference counting doesn't work when you try
> > to use the same global pointer (usb_class) to refer to multiple
> > generations of a dynamically allocated entity.  We had the same sort of
> > problem many years ago with the usb_interface structure (and we
> > ultimately fixed it by creating a separate usb_interface_cache
> > structure).
> >  
> > The best approach here would be to forget about all the reference
> > counting.  Get rid of usb_class entirely, and create the "usbmisc"
> > class structure just once, when usbcore initializes.  Or, if you
> > prefer, use a mutex to protect a routine that allocates the class
> > structure dynamically, just once.  Either way, don't deallocate it
> > until usbcore is unloaded.
> 
> usbmisc class creation should not require everytime when USB core
> initializes. So better to keep usbmisc class creation as it is. 
> And to prevent the race conditions just protect it with Mutex locking
> as per patch v2.
> 
> thanks,
> ajay kaher
> 
> Signed-off-by: Ajay Kaher
> 
> ---
> 
>  drivers/usb/core/file.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..56a151b 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -102,9 +103,11 @@ static int init_usb_class(void)
>  static void release_usb_class(struct kref *kref)
>  {
> /* Ok, we cheat as we know we only have one usb_class */
> +   mutex_lock(_usb_class_mutex);
> class_destroy(usb_class->class);
> kfree(usb_class);
> usb_class = NULL;
> +   mutex_unlock(_usb_class_mutex);
>  }
> 
>  static void destroy_usb_class(void)
> @@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
> 
> +   mutex_lock(_usb_class_mutex);
> retval = init_usb_class();
> +   mutex_unlock(_usb_class_mutex);
> +
> if (retval)
> return retval;

This is not right.  What happens if usb_register_dev() runs just before
release_usb_class() calls mutex_lock()?

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: RE: Re: Re: Re: Subject: [PATCH v2] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

 
> > At boot time, probe function of multiple connected devices
> > (proprietary devices) execute simultaneously.
> 
>  What exactly do you mean here?  How can probe happen "simultaneously"?
>  The USB core prevents this, right?
>  
>> >>> I have observed two scenarios to call probe function:
>> >>> 
>> >>> Scenario #1: Driver inserted and attaching USB Device:
>> >>> Yes, you are right, two probes at same time is not happening
>> >> in this scenario.
>> >> 
>> >> Scenario #2: USB Device attached and inserting Driver:
>> >> In this case probe has been called in context of insmod,
>> >> refer following code flow:
>> >> init -> usb_register_driver -> driver_register -> bus_add_driver ->
>> >> driver_attach -> bus_for_each_dev -> __driver_attach ->
>> >> driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev
>> >> 
>> >> I have observed the crash in Scenario #2, as two probes executes at
>> >> same time in this scenario. And init_usb_class_mutex lock require to
>> >> prevent race condition.
>> > 
>> > What about the fact that in __driver_attach() we call device_lock() so
>> > that probe never gets called at the same time for the same device?
>> 
>> Devices are different.
>> 
>> > Or are you saying that you can load multiple USB modules at the same
>> > time?  If so, how is insmod running on multiple cpus at the same time?
>> > I thought we had a global lock there to prevent that from happening
>> > (i.e. only one module can be loaded at a time.)  Or is that what has
>> > recently changed?
>> 
>> Yes, we can load multiple USB modules at the same time using insmod.
>> Tested on ARM Architecture with Linux kernel 4.1.10, that we can have 
>> multiple insmod on multiple cpus at same time. Also reviewed load_module and 
>> do_init_module functions and couldn't find any global lock.
>> 
>> > 
>> > What is causing your modules to be loaded from userspace?  What type of
>> > device is this happening for?  And why haven't we seen this before?
>> > What kernel versions have you had a problem with this?
>> 
>> Earlier we execute insmod in foreground as "insmod aaa.ko ; insmod bbb.ko"
>> and that's why insmod executed sequentially. Now we modified to execute in 
>> parallel/background as "insmod aaa.ko & ; insmod bbb.ko &". 
>> 
>> > And what for what drivers specifically?
>> 
>> This problem observed for drivers in which usb_register_dev called from their
>> probe function, and there are many such drivers.
>> 
>> As per my opinion, usb_class structure is global and allocated + initialized
>> in usb_register_dev->init_usb_class function. Also as per scenario #2
>> concurrency is possible, so protection using init_usb_class_mutex lock 
>>requires.
>> Don't you think so?
>> 
>>  And because of the following code path race condition happens:
>>  probe->usb_register_dev->init_usb_class
>> >>>
>> >>> Why is this just showing up now, and hasn't been an issue for the decade
>> >>> or so this code has been around?  What changed?
>> >>>
>>  Tested with these changes, and problem has been solved.
>> >>>
>> >>> What changes?
>> >> 
>> >> Tested with my patch (i.e. locking with init_usb_class_mutex).
>> > 
>> > I don't see a patch here :(
>> 
>> Sorry, appending the patch again with this mail.
>>  
>> thanks,
>>  
>> ajay kaher
>> 
>> 
>
> On Thu, 14 Feb 2017, Alan Stern wrote:
> 
> I think Ajay's argument is correct and a patch is needed.  But this
> patch misses the race between init_usb_class() and release_usb_class().  

Thanks Alan for your comments, in patch v2 I have taken care for
release_usb_class() also. Please review again.

> The basic problem is that reference counting doesn't work when you try
> to use the same global pointer (usb_class) to refer to multiple
> generations of a dynamically allocated entity.  We had the same sort of
> problem many years ago with the usb_interface structure (and we
> ultimately fixed it by creating a separate usb_interface_cache
> structure).
>  
> The best approach here would be to forget about all the reference
> counting.  Get rid of usb_class entirely, and create the "usbmisc"
> class structure just once, when usbcore initializes.  Or, if you
> prefer, use a mutex to protect a routine that allocates the class
> structure dynamically, just once.  Either way, don't deallocate it
> until usbcore is unloaded.

usbmisc class creation should not require everytime when USB core
initializes. So better to keep usbmisc class creation as it is. 
And to prevent the race conditions just protect it with Mutex locking
as per patch v2.

thanks,
ajay kaher

Signed-off-by: Ajay Kaher

---

 drivers/usb/core/file.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..56a151b 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static 

Re: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Wed, Feb 01, 2017 at 07:24:44AM +, Ajay Kaher wrote:
>  
> >> At boot time, probe function of multiple connected devices
> >> (proprietary devices) execute simultaneously.
> >
> >What exactly do you mean here?  How can probe happen "simultaneously"?
> >The USB core prevents this, right?
> 
> I have observed two scenarios to call probe function:
> 
> Scenario #1: Driver inserted and attaching USB Device:
> Yes, you are right, two probes at same time is not happening
> in this scenario.
> 
> Scenario #2: USB Device attached and inserting Driver:
> In this case probe has been called in context of insmod,
> refer following code flow:
> init -> usb_register_driver -> driver_register -> bus_add_driver ->
> driver_attach -> bus_for_each_dev -> __driver_attach ->
> driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev
> 
> I have observed the crash in Scenario #2, as two probes executes at
> same time in this scenario. And init_usb_class_mutex lock require to
> prevent race condition.

What about the fact that in __driver_attach() we call device_lock() so
that probe never gets called at the same time for the same device?

Or are you saying that you can load multiple USB modules at the same
time?  If so, how is insmod running on multiple cpus at the same time?
I thought we had a global lock there to prevent that from happening
(i.e. only one module can be loaded at a time.)  Or is that what has
recently changed?

What is causing your modules to be loaded from userspace?  What type of
device is this happening for?  And why haven't we seen this before?
What kernel versions have you had a problem with this?

And what for what drivers specifically?

> >> And because of the following code path race condition happens:
> >> probe->usb_register_dev->init_usb_class
> >
> >Why is this just showing up now, and hasn't been an issue for the decade
> >or so this code has been around?  What changed?
> >
> >> Tested with these changes, and problem has been solved.
> >
> >What changes?
> 
> Tested with my patch (i.e. locking with init_usb_class_mutex).

I don't see a patch here :(

thanks,

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

RE: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

 
>> At boot time, probe function of multiple connected devices
>> (proprietary devices) execute simultaneously.
>
>What exactly do you mean here?  How can probe happen "simultaneously"?
>The USB core prevents this, right?

I have observed two scenarios to call probe function:

Scenario #1: Driver inserted and attaching USB Device:
Yes, you are right, two probes at same time is not happening
in this scenario.

Scenario #2: USB Device attached and inserting Driver:
In this case probe has been called in context of insmod,
refer following code flow:
init -> usb_register_driver -> driver_register -> bus_add_driver ->
driver_attach -> bus_for_each_dev -> __driver_attach ->
driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev

I have observed the crash in Scenario #2, as two probes executes at
same time in this scenario. And init_usb_class_mutex lock require to
prevent race condition.

>> And because of the following code path race condition happens:
>> probe->usb_register_dev->init_usb_class
>
>Why is this just showing up now, and hasn't been an issue for the decade
>or so this code has been around?  What changed?
>
>> Tested with these changes, and problem has been solved.
>
>What changes?

Tested with my patch (i.e. locking with init_usb_class_mutex).

thanks,

ajay kaher


 
- Original Message -
Sender : gre...@linuxfoundation.org <gre...@linuxfoundation.org>
Date   : 2017-01-31 12:31 (GMT+5:30)
Title  : Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race 
Condition when two USB class drivers try to call init_usb_class simultaneously
 
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
 
A: No.
Q: Should I include quotations after my reply?
 
 
http://daringfireball.net/2007/07/on_top
 
On Tue, Jan 31, 2017 at 05:21:46AM +, Ajay Kaher wrote:
> 
>  
> At boot time, probe function of multiple connected devices
> (proprietary devices) execute simultaneously.
 
What exactly do you mean here?  How can probe happen "simultaneously"?
The USB core prevents this, right?
 
And what do you mean exactly by "(proprietary devices)"?
 
> And because of the following code path race condition happens:
> probe->usb_register_dev->init_usb_class
 
Why is this just showing up now, and hasn't been an issue for the decade
or so this code has been around?  What changed?
 
> Tested with these changes, and problem has been solved.
 
What changes?
 
thanks,
 
greg k-h
 
 
Thanks and Regards,
Ajay Kaher

Re: [PATCH] Subject: usb/serial/pl2303 add ATEN device ID

[Johan Hovold]

On Mon, Jan 30, 2017 at 07:26:40PM +0100, Marcel J.E. Mol wrote:
> 
> Seems that ATEN serial-to-usb devices using pl2303 exist with
> different device ids. This patch adds a missing device ID so it
> is recognised by the driver.
> 
> Signed-off-by: Marcel J.E. Mol <mar...@mesa.nl>
> ---

Thanks for the patch. I dropped that stray "Subject: " from the commit
summary and changed it to

"USB: serial: pl2303: add ATEN device ID"

before applying.

When replying to this one the first time I noticed that you'd also
gotten the linux-usb mailing list address wrong. Fixed up and resent
with full context now.

Johan

>  drivers/usb/serial/pl2303.c | 2 ++
>  drivers/usb/serial/pl2303.h | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index 46fca6b..8e61975 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -49,7 +49,8 @@ static const struct usb_device_id id_table[] = {
>   { USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID) },
>   { USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID_RSAQ5) },
>   { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID) },
> + { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
>   { USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
>   { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
>   { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID_UCSGT) },
>   { USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID) },
> diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
> index e3b7af8..09d9be8 100644
> --- a/drivers/usb/serial/pl2303.h
> +++ b/drivers/usb/serial/pl2303.h
> @@ -27,6 +27,7 @@
>  #define ATEN_VENDOR_ID   0x0557
>  #define ATEN_VENDOR_ID2  0x0547
>  #define ATEN_PRODUCT_ID  0x2008
> +#define ATEN_PRODUCT_ID2 0x2118
>  
>  #define IODATA_VENDOR_ID 0x04bb
>  #define IODATA_PRODUCT_ID0x0a03
--
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: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Tue, Jan 31, 2017 at 05:21:46AM +, Ajay Kaher wrote:
> 
>  
> At boot time, probe function of multiple connected devices
> (proprietary devices) execute simultaneously.

What exactly do you mean here?  How can probe happen "simultaneously"?
The USB core prevents this, right?

And what do you mean exactly by "(proprietary devices)"?

> And because of the following code path race condition happens:
> probe->usb_register_dev->init_usb_class

Why is this just showing up now, and hasn't been an issue for the decade
or so this code has been around?  What changed?

> Tested with these changes, and problem has been solved.

What changes?

thanks,

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

RE: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

 
At boot time, probe function of multiple connected devices
(proprietary devices) execute simultaneously. And because
of the following code path race condition happens:
probe->usb_register_dev->init_usb_class

Tested with these changes, and problem has been solved.

thanks,
ajay kaher


- Original Message -
Sender : gre...@linuxfoundation.org <gre...@linuxfoundation.org>
Date   : 2017-01-30 14:36 (GMT+5:30)
Title  : Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race 
Condition when two USB class drivers try to call init_usb_class simultaneously
 
On Mon, Jan 30, 2017 at 08:25:25AM +, Ajay Kaher wrote:
>  
 
First off, you are sending html email, which the mailing list keeps
rejecting, why are you ignoring that?
 
 
 
> 
> There is race condition when two USB class drivers try to call
> 
> init_usb_class at the same time and leads to crash.
> 
>  
> 
> The main reason for this is one of the Class drivers allocates memory
> for usb_class structure and initializes its member. In the meantime NULL
> check for usb_class structure fails and assumes that usb_class structure
> is properly initialized and crashed while trying to access its members.
> 
>  
> 
> To avoid this race condition locking required before calling
> init_usb_class from function usb_register_dev.
> 
>  
> 
>  
> 
> Signed-off-by: Ajay Kaher
 
Does this look correct?  Please work with some of the samsung kernel
developers for how to properly submit a patch.
 
And finally, how are two drivers calling init_usb_class() at the same
time?  What code path causes that?  Have you seen this happen, and if
so, what drivers caused it?
 
thanks,
 
greg k-h
 
 

Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Mon, Jan 30, 2017 at 08:25:25AM +, Ajay Kaher wrote:
>  

First off, you are sending html email, which the mailing list keeps
rejecting, why are you ignoring that?



> 
> There is race condition when two USB class drivers try to call
> 
> init_usb_class at the same time and leads to crash.
> 
>  
> 
> The main reason for this is one of the Class drivers allocates memory
> for usb_class structure and initializes its member. In the meantime NULL
> check for usb_class structure fails and assumes that usb_class structure
> is properly initialized and crashed while trying to access its members.
> 
>  
> 
> To avoid this race condition locking required before calling
> init_usb_class from function usb_register_dev.
> 
>  
> 
>  
> 
> Signed-off-by: Ajay Kaher

Does this look correct?  Please work with some of the samsung kernel
developers for how to properly submit a patch.

And finally, how are two drivers calling init_usb_class() at the same
time?  What code path causes that?  Have you seen this happen, and if
so, what drivers caused it?

thanks,

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

[no subject]

[Joe Bryant]

Sup linux

euroautotechinc.com/upgrade.php?forward=2c217epf3dcb



Joe
--
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

[no subject]

[christina koch]

Ciao,

è un piacere conoscerti.Io sono Christina H. Koch, uno Stato ufficiale
dell'Esercito da stati uniti d'America,ho una cosa importante da
discutere con te, che può portare a un business partner o
qualcos'altro, mi presento meglio e inviare le mie foto non appena ho
ricevuto la tua mail.

Christina.
--
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

[no subject]

[Ryan]

 auth 12a8a74f subscribe linux-usb ryanphilip...@googlemail.com
--
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

[no subject]

[John Youn]

>From 1ea511f4fd3ed082beee53130625570a6b6b8d82 Mon Sep 17 00:00:00 2001
Message-Id: 
<1ea511f4fd3ed082beee53130625570a6b6b8d82.1480378291.git.johny...@synopsys.com>
Subject: [PATCH] usb: dwc3: pci: Add "linux,sysdev_is_parent" property
To: Felipe Balbi <ba...@kernel.org>, linux-usb@vger.kernel.org
Cc: John Youn <johny...@synopsys.com>, Sriram Dash <sriram.d...@nxp.com>, 
Baolin Wang <baolin.w...@linaro.org>, Arnd Bergmann <a...@arndb.de>

Calling platform_device_add_properties() replaces existing properties so
the "linux,sysdev_is_parent" property doesn't get set. Add this property
to each platform.

Fixes: d64ff406e51e ("usb: dwc3: use bus->sysdev for DMA configuration")
Signed-off-by: John Youn <johny...@synopsys.com>
---

Hi Felipe,

Can you queue for 4.10 fixes? The original commit breaks HAPS.

Regards,
John



 drivers/usb/dwc3/dwc3-pci.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 2b73339..d13f771 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -73,16 +73,6 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
 {
struct platform_device  *dwc3 = dwc->dwc3;
struct pci_dev  *pdev = dwc->pci;
-   int ret;
-
-   struct property_entry sysdev_property[] = {
-   PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
-   { },
-   };
-
-   ret = platform_device_add_properties(dwc3, sysdev_property);
-   if (ret)
-   return ret;
 
if (pdev->vendor == PCI_VENDOR_ID_AMD &&
pdev->device == PCI_DEVICE_ID_AMD_NL_USB) {
@@ -105,6 +95,7 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
PROPERTY_ENTRY_BOOL("snps,disable_scramble_quirk"),
PROPERTY_ENTRY_BOOL("snps,dis_u3_susphy_quirk"),
PROPERTY_ENTRY_BOOL("snps,dis_u2_susphy_quirk"),
+   PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
{ },
};
 
@@ -116,6 +107,7 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
 
struct property_entry properties[] = {
PROPERTY_ENTRY_STRING("dr-mode", "peripheral"),
+   PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
{ }
};
 
@@ -167,6 +159,7 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
PROPERTY_ENTRY_BOOL("snps,usb3_lpm_capable"),
PROPERTY_ENTRY_BOOL("snps,has-lpm-erratum"),
PROPERTY_ENTRY_BOOL("snps,dis_enblslpm_quirk"),
+   PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
{ },
};
 
-- 
2.10.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

[no subject]

[Debra_Farmer/SSB/HIDOE]

I am Mrs. Gu Kailai and i intend to make a DONATION. Contact my personal E-mail 
Via: mrsgukai...@post.cz for more details:
--
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

[no subject]

[Benjamin Staton]

The Issue: Scanning (with xsane 0.999) while using kernel 4.8 (I
tested 4.8 rc1, rc5, rc7, rc8, and 4.8.1) fails when the scanner
becomes disconnected from the USB bus.  Every time.

Scanning (with xsane 0.999) while using kernel 4.7.0 or earlier 4's
works without fail.

My scanner is known to lsusb as "Bus 006 Device 002: ID 04a9:2206
Canon, Inc. CanoScan N650U/N656U" and to Xsane as "Canon CanoScan
N650U/N flatbed scanner [plustek:libusb:006:002]".

Relevant lines from /var/log/kern.log at the time of the disconnect:
Oct 14 13:30:00 quiz kernel: [  167.746817] ohci-pci :00:12.0:
HcDoneHead not written back; disabled
Oct 14 13:30:00 quiz kernel: [  167.746829] ohci-pci :00:12.0: HC
died; cleaning up
Oct 14 13:30:00 quiz kernel: [  167.746916] usb 6-1: USB disconnect,
device number 2
Oct 14 13:30:00 quiz kernel: [  167.747618] usb 6-3: USB disconnect,
device number 3
Oct 14 13:30:00 quiz kernel: [  167.747624] usb 6-3.2: USB disconnect,
device number 4
Oct 14 13:30:00 quiz kernel: [  167.803283] usb 6-3.3: USB disconnect,
device number 5

This is on an asrock 970M Pro3 motherboard w/AMD FX-8300 CPU and 32GB
RAM running debian testing/9.  Kernels built from kernel.org without
further patching.

Apologies for posting to wrong place (bugzilla) and happy to provide more info.

Thanks,
Joe
--
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

[no subject]

[Amitesh Singh]

auth e47dc987 subscribe linux-usb singh.amit...@gmail.com
--
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

[no subject]

[Aleksandr Makarov]

unsubscribe linux-usb
--
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

[no subject]

[Jeffrey Chu]

unsubscribe 
--
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

[no subject]

[Jeffrey Chu]

unsubscsribe
--
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

[no subject]

[bob]

Hello LKML. I have had a small ASUS usb screen gadget that came with my 
motherboard. Its been sitting on my desk for about 7 years. Having 
exhausted my patience waiting for a nifty Linux app to drive it, I wrote 
one. If you have such a beast and want the app, go to 
https://github.com/mayorbobster/screenduo4linux If you aren't 
interested, please disregard this notice. Thank you.





--
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

[no subject]

[Brian Park]

subscribe linux-usb
--
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

[no subject]

[Johan Hovold]

The following changes since commit 74bf8efb5fa6e958d2d7c7917b8bb672085ec0c6:

  Linux 4.4-rc7 (2015-12-27 18:17:37 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.4-rc8

for you to fetch changes up to f7d7f59ab124748156ea551edf789994f05da342:

  USB: cp210x: add ID for ELV Marble Sound Board 1 (2015-12-28 19:07:35 +0100)


USB-serial fixes for v4.4-rc8

Here's another device id for cp210x.

Signed-off-by: Johan Hovold 


Oliver Freyermuth (1):
  USB: cp210x: add ID for ELV Marble Sound Board 1

 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)
--
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

[no subject]

[Martin MOKREJŠ]

subscribe
--
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

[no subject]

[Kussner, Sara]

Please contact me about this project (mrsyuen@outlook.com)
Regards
--
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

[no subject]

[Chunfeng Yun]

From ac1e8724bfa47494223bad0af450c1a63cd2fe0c Mon Sep 17 00:00:00 2001
From: Chunfeng Yun chunfeng@mediatek.com
Date: Wed, 22 Jul 2015 21:15:15 +0800
Subject: [PATCH 0/5] *** SUBJECT HERE ***

The patch supports MediaTek's xHCI controller.

There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.

2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.

3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.

A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.

Change in v3:
1. implement generic phy
2. move opperations for IPPC and wakeup from phy driver to xHCI driver
3. seperate quirk functions into a single C file to fix up dependence issue

Chunfeng Yun (5):
  dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
  dt-bindings: Add a binding for Mediatek xHCI host controller
  usb: phy: add usb3.0 phy driver for mt65xx SoCs
  xhci: mediatek: support MTK xHCI host controller
  arm64: dts: mediatek: add xHCI  usb phy for mt8173

 .../devicetree/bindings/phy/phy-mt65xx-u3.txt  |  21 +
 .../devicetree/bindings/usb/mt8173-xhci.txt|  50 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|  15 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  31 +
 drivers/phy/Kconfig|   9 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-mt65xx-usb3.c  | 426 +++
 drivers/usb/host/Kconfig   |   9 +
 drivers/usb/host/Makefile  |   4 +
 drivers/usb/host/xhci-mtk-sch.c| 436 +++
 drivers/usb/host/xhci-mtk.c| 836 +
 drivers/usb/host/xhci-mtk.h| 135 
 drivers/usb/host/xhci-ring.c   |  35 +-
 drivers/usb/host/xhci.c|  19 +-
 drivers/usb/host/xhci.h|   1 +
 15 files changed, 2021 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-u3.txt
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

--
1.8.1.1.dirty

In-Reply-To: 

--
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

[no subject]

[pepa6...@ono.com]

Proposal,

Respond to my personal email;  mrs.zhangxiao1962@outlook.
com 


Yours Sincerely.
Mrs. Zhang Xiao (Accounts book Keeper)
Angang 
Steel Company Limited
396 Nan Zhong Hua Lu, Tie Dong District Anshan, 
Liaoning 114021, China.

--
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

[no subject]

[Leanne Armstrong]

You were selected for QATAR Foundation 2015 beneficiaries contact 
RodFalusi(rodrigofalus...@yahoo.co.zamailto:rodrigofalus...@yahoo.co.za)
--
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

[no subject]

[steve]

1) Summary pasted
 summary: scanimage -L finds fitjitsu 04c5:11fc but if repeated does 
not find it

+ 04c5:11fc [System76 gazp9b] Excuting scanimage -L finds Fujitsu 6110
+ Scanner but if repeated does not


2) full description:
i plug a fitjitsu 04c5:11fc into a usb2.0 plug
lsusb shows the equipment
command line simple-scan, scanimage -L or sane-find_scanner does not find it

3) Keywords

4) kernel version 3.18-vivid

5) syslog:
Dec 14 12:53:48 skc kernel: [ 219.200113] usb 1-2: new high-speed USB 
device number 5 using xhci_hcd
Dec 14 12:53:48 skc kernel: [ 219.390380] usb 1-2: New USB device found, 
idVendor=04c5, idProduct=11fc
Dec 14 12:53:48 skc kernel: [ 219.390384] usb 1-2: New USB device 
strings: Mfr=0, Product=0, SerialNumber=0
Dec 14 12:53:48 skc kernel: [ 219.390563] usb 1-2: ep 0x81 - rounding 
interval to 128 microframes, ep desc says 255 microframes
Dec 14 12:53:48 skc kernel: [ 219.390567] usb 1-2: ep 0x2 - rounding 
interval to 128 microframes, ep desc says 255 microframes

Dec 14 12:53:48 skc colord: Device added: sysfs-04c5-11fc

6)
scanimage -L
simple-scan
sane-find-scanner
do not find any scanner

7) lsb_release -rd
Description:Ubuntu 14.04.1 LTS
Release:14.04

7.1) 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 skc 3.18.0-031800-generic #201412071935 SMP Mon Dec 8 00:36:34 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux


Gnu C  4.8
Gnu make   3.81
binutils   2.24
util-linux 2.20.1
mount  support
module-init-tools  15
e2fsprogs  1.42.9
pcmciautils018
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.21
wireless-tools 30
Modules Loaded xt_conntrack ipt_REJECT nf_reject_ipv4 
ip6table_filter ip6_tables ebtable_nat ebtables xt_CHECKSUM 
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 ctr iptable_nat ccm 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables rfcomm bnep 
arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp iwlmvm coretemp 
mac80211 kvm_intel kvm uvcvideo snd_hda_codec_via videobuf2_vmalloc 
snd_hda_codec_generic snd_hda_codec_hdmi crct10dif_pclmul 
videobuf2_memops iwlwifi videobuf2_core crc32_pclmul v4l2_common 
ghash_clmulni_intel videodev aesni_intel media aes_x86_64 cfg80211 
snd_hda_intel lrw btusb gf128mul joydev glue_helper bluetooth 
ablk_helper snd_hda_controller serio_raw cryptd rtsx_pci_ms 
snd_hda_codec memstick lpc_ich snd_hwdep mei_me i915 wmi mei snd_pcm 
tpm_infineon mac_hid snd_seq_midi snd_seq_midi_event snd_rawmidi video 
snd_seq drm_kms_helper snd_se
q_device drm snd_timer snd i2c_algo_bit soundcore ie31200_edac 
parport_pc edac_core ppdev lp parport rtsx_pci_sdmmc psmouse r8169 ahci 
libahci mii rtsx_pci



7,2) /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 60
model name: Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
stepping: 3
microcode: 0x17
cpu MHz: 2515.917
cache size: 6144 KB
physical id: 0
siblings: 8
core id: 0
cpu cores: 4
apicid: 0
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor 
ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe 
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat 
epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt

bugs:
bogomips: 4988.89
clflush size: 64
cache_alignment: 64
address sizes: 39 bits physical, 48 bits virtual
power management:

processor: 1
vendor_id: GenuineIntel
cpu family: 6
model: 60
model name: Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
stepping: 3
microcode: 0x17
cpu MHz: 2500.000
cache size: 6144 KB
physical id: 0
siblings: 8
core id: 1
cpu cores: 4
apicid: 2
initial apicid: 2
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor 
ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe 
popcnt tsc_deadline_timer aes 

[no subject]

[Andrew Sullivan]

[1.] One line summary of the problem:

[Lenovo G505s] External USB3 drive not accessible via USB 3.0 port



[2.] Full description of the problem/report:

When external USB HD is plugged into the USB3 port on the laptop, it
is not seen by the machine.  It is seen when plugged into a USB2 port.

[3.] Keywords (i.e., modules, networking, kernel):

[4.] Kernel version (from /proc/version):

Linux version 3.18.0-031800rc4-generic (apw@gomeisa) (gcc version
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201411091835 SMP Sun Nov 9
23:36:36 UTC 2014

[5.] Output of Oops.. message (if applicable) with symbolic
information resolved (see Documentation/oops-tracing.txt)

n/a

[6.] A small shell script or example program which triggers the
problem (if possible)

Probably not relevant

[7.] Environment

Description:Ubuntu 14.10
Release: 14.10

[7.1.] Software (add the output of the ver_linux script here)

Cannot find entry for version 3.18, despite what output from /proc/version says.

[7.2.] Processor information (from /proc/cpuinfo):

See above

[7.3.] Module information (from /proc/modules):

See above

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)

See above

[7.5.] PCI information ('lspci -vvv' as root)

See above

[7.6.] SCSI information (from /proc/scsi/scsi)

See above

[7.7.] Other information that might be relevant to the problem (please
look in /proc and include all information that you think to be
relevant):

See above

[X.] Other notes, patches, fixes, workarounds:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1390772
--
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

[no subject]

[Angelo Dureghello]

unsubscribe linux-usb angel...@gmail.com
--
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

[no subject]

[Haibo Zhang]

Hello,

We know that dwc2 is the USB2.0 driver for DesignWare IP. But it only
has host’s code
without device’s code. So I have two questions:
1.   Will I develop or port the part of device’s code if I want to
use dwc2 to support both
host and device’s functions?
2.   Another question, I know that many chip companies use dwc2.
How do they solve the
question above?

If anyone has a similar experience or know well about this dwc2
driver, please reply me.
Any help will be greatly appreciated.

Thanks,

-- 


*Zhang Haibo*
--
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

[no subject]

[Sebastian Andrzej Siewior]

I have two musb instances running in OTG. One instance is in device mode,
the other in host mode. I enable remote wakeup for both ports
(echo 1  /sys/…/power/wakeup). On leaving suspend I see that the root-hub
is resumed twice. I added a printk to hub_activate to see the device
name and active-type + a WARN_ON(type == HUB_RESUME) and I see:

|echo standby  /sys/power/state
| PM: Syncing filesystems ... done.
| PM: Preparing system for standby sleep
| Freezing user space processes ... (elapsed 0.001 seconds) done.
| Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
| PM: Entering standby sleep
| Suspending console(s) (use no_console_suspend to debug)
| PM: suspend of devices complete after 6.608 msecs
| PM: late suspend of devices complete after 0.890 msecs
| PM: noirq suspend of devices complete after 1.086 msecs
| PM: Successfully put all powerdomains to target state
| PM: Wakeup source UART
| PM: noirq resume of devices complete after 16.454 msecs
| PM: early resume of devices complete after 0.684 msecs
| hub_activate(1024) usb1 4
| [ cut here ]
| WARNING: CPU: 0 PID: 761 at drivers/usb/core/hub.c:1025 
hub_activate+0x4a4/0x4dc()
| CPU: 0 PID: 761 Comm: kworker/u2:2 Not tainted 3.14.23+ #287
| Workqueue: events_unbound async_run_entry_fn
| [c0013cdc] (unwind_backtrace) from [c00113f8] (show_stack+0x10/0x14)
| [c00113f8] (show_stack) from [c003fec0] (warn_slowpath_common+0x68/0x88)
| [c003fec0] (warn_slowpath_common) from [c003fefc] 
(warn_slowpath_null+0x1c/0x24)
| [c003fefc] (warn_slowpath_null) from [c043c588] (hub_activate+0x4a4/0x4dc)
| [c043c588] (hub_activate) from [c043c624] (hub_resume+0x14/0x1c)
| [c043c624] (hub_resume) from [c0446d54] 
(usb_resume_interface.isra.2+0x100/0x140)
| [c0446d54] (usb_resume_interface.isra.2) from [c0446e00] 
(usb_resume_both+0x6c/0x13c)
| [c0446e00] (usb_resume_both) from [c04476f4] (usb_resume+0x14/0x60)
| [c04476f4] (usb_resume) from [c0439cc8] (usb_dev_resume+0xc/0x10)
| [c0439cc8] (usb_dev_resume) from [c0391a9c] (dpm_run_callback+0x34/0x70)
| [c0391a9c] (dpm_run_callback) from [c0391b90] (device_resume+0xb8/0x21c)
| [c0391b90] (device_resume) from [c0391d0c] (async_resume+0x18/0x44)
| [c0391d0c] (async_resume) from [c005f42c] (async_run_entry_fn+0x40/0x170)
| [c005f42c] (async_run_entry_fn) from [c0054bf4] 
(process_one_work+0x128/0x3b4)
| [c0054bf4] (process_one_work) from [c0054fc0] (worker_thread+0x10c/0x364)
| [c0054fc0] (worker_thread) from [c005a534] (kthread+0xbc/0xd8)
| [c005a534] (kthread) from [c000e538] (ret_from_fork+0x14/0x3c)
| ---[ end trace 005fc846a215a40c ]---
| PM: Finishing wakeup.
| Restarting tasks ... 
| hub_activate(1024) usb1 4
| [ cut here ]
| WARNING: CPU: 0 PID: 372 at drivers/usb/core/hub.c:1025 
hub_activate+0x4a4/0x4dc()
| CPU: 0 PID: 372 Comm: khubd Tainted: GW3.14.23+ #287
| [c0013cdc] (unwind_backtrace) from [c00113f8] (show_stack+0x10/0x14)
| [c00113f8] (show_stack) from [c003fec0] (warn_slowpath_common+0x68/0x88)
| [c003fec0] (warn_slowpath_common) from [c003fefc] 
(warn_slowpath_null+0x1c/0x24)
| [c003fefc] (warn_slowpath_null) from [c043c588] (hub_activate+0x4a4/0x4dc)
| [c043c588] (hub_activate) from [c043c624] (hub_resume+0x14/0x1c)
| [c043c624] (hub_resume) from [c0446d54] 
(usb_resume_interface.isra.2+0x100/0x140)
| [c0446d54] (usb_resume_interface.isra.2) from [c0446e00] 
(usb_resume_both+0x6c/0x13c)
| [c0446e00] (usb_resume_both) from [c0447bec] 
(usb_runtime_resume+0x10/0x14)
| [c0447bec] (usb_runtime_resume) from [c0394468] (rpm_callback+0x9c/0xb8)
| [c0394468] (rpm_callback) from [c0395370] (rpm_resume+0x330/0x560)
| [c0395370] (rpm_resume) from [c0395238] (rpm_resume+0x1f8/0x560)
| [c0395238] (rpm_resume) from [c039579c] (__pm_runtime_resume+0x18/0x40)
| [c039579c] (__pm_runtime_resume) from [c0446510] 
(usb_autopm_get_interface+0x18/0x5c)
| [c0446510] (usb_autopm_get_interface) from [c043ecb4] 
(hub_thread+0xf4/0x10c4)
| [c043ecb4] (hub_thread) from [c005a534] (kthread+0xbc/0xd8)
| [c005a534] (kthread) from [c000e538] (ret_from_fork+0x14/0x3c)
| ---[ end trace 005fc846a215a40e ]---
| done.
| [ cut here ]
| WARNING: CPU: 0 PID: 372 at drivers/usb/core/urb.c:339 
usb_submit_urb+0x494/0x4c8()
| URB ddd59f80 submitted while active
| CPU: 0 PID: 372 Comm: khubd Tainted: GW3.14.23+ #287
| [c0013cdc] (unwind_backtrace) from [c00113f8] (show_stack+0x10/0x14)
| [c00113f8] (show_stack) from [c003fec0] (warn_slowpath_common+0x68/0x88)
| [c003fec0] (warn_slowpath_common) from [c003ff74] 
(warn_slowpath_fmt+0x30/0x40)
| [c003ff74] (warn_slowpath_fmt) from [c0443ec8] 
(usb_submit_urb+0x494/0x4c8)
| [c0443ec8] (usb_submit_urb) from [c043c308] (hub_activate+0x224/0x4dc)
| [c043c308] (hub_activate) from [c043c624] (hub_resume+0x14/0x1c)
| [c043c624] (hub_resume) from [c0446d54] 
(usb_resume_interface.isra.2+0x100/0x140)
| [c0446d54] (usb_resume_interface.isra.2) from [c0446e00] 
(usb_resume_both+0x6c/0x13c)
| 

Subject: [PATCH] usb: gadget: function: Remove redundant usb_free_all_descriptors

[pavi1729 Sid]

Removed the usb_free_all_descriptors call in *_bind functions
as this call is already present in usb_assign_descriptors.
usb_assign_descriptors is the only call where usb descriptor
allocation happens, also in case of error freeing of the
allocated memory takes place in the same call. Hence the
call in the *_bind functions are redundant.
Also the presence of usb_free_all_descriptors in the *_bind
functions might result in double-free corruption of the
allocated mmeory.

Signed-off-by: Pavitrakumar Managutte pavitra1...@gmail.com
---
 drivers/usb/gadget/function/f_eem.c|  1 -
 drivers/usb/gadget/function/f_hid.c|  7 +++
 drivers/usb/gadget/function/f_ncm.c|  1 -
 drivers/usb/gadget/function/f_phonet.c |  1 -
 drivers/usb/gadget/function/f_rndis.c  |  5 +++--
 drivers/usb/gadget/function/f_subset.c |  1 -
 drivers/usb/gadget/function/f_uac2.c   | 10 ++
 7 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/function/f_eem.c
b/drivers/usb/gadget/function/f_eem.c
index 4d8b236..c9e90de 100644
--- a/drivers/usb/gadget/function/f_eem.c
+++ b/drivers/usb/gadget/function/f_eem.c
@@ -325,7 +325,6 @@ static int eem_bind(struct usb_configuration *c,
struct usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 if (eem-port.out_ep)
 eem-port.out_ep-driver_data = NULL;
 if (eem-port.in_ep)
diff --git a/drivers/usb/gadget/function/f_hid.c
b/drivers/usb/gadget/function/f_hid.c
index a95290a..c36de0c 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -621,12 +621,14 @@ static int __init hidg_bind(struct
usb_configuration *c, struct usb_function *f)
 dev = MKDEV(major, hidg-minor);
 status = cdev_add(hidg-cdev, dev, 1);
 if (status)
-goto fail;
+goto fail_free_descs;

 device_create(hidg_class, NULL, dev, NULL, %s%d, hidg, hidg-minor);

 return 0;

+fail_free_descs:
+usb_free_all_descriptors(f);
 fail:
 ERROR(f-config-cdev, hidg_bind FAILED\n);
 if (hidg-req != NULL) {
@@ -635,7 +637,6 @@ fail:
 usb_ep_free_request(hidg-in_ep, hidg-req);
 }

-usb_free_all_descriptors(f);
 return status;
 }

@@ -652,8 +653,6 @@ static void hidg_unbind(struct usb_configuration
*c, struct usb_function *f)
 kfree(hidg-req-buf);
 usb_ep_free_request(hidg-in_ep, hidg-req);

-usb_free_all_descriptors(f);
-
 kfree(hidg-report_desc);
 kfree(hidg);
 }
diff --git a/drivers/usb/gadget/function/f_ncm.c
b/drivers/usb/gadget/function/f_ncm.c
index bcdc882..38a9279 100644
--- a/drivers/usb/gadget/function/f_ncm.c
+++ b/drivers/usb/gadget/function/f_ncm.c
@@ -1453,7 +1453,6 @@ static int ncm_bind(struct usb_configuration *c,
struct usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 if (ncm-notify_req) {
 kfree(ncm-notify_req-buf);
 usb_ep_free_request(ncm-notify, ncm-notify_req);
diff --git a/drivers/usb/gadget/function/f_phonet.c
b/drivers/usb/gadget/function/f_phonet.c
index b9cfc15..74ddcac 100644
--- a/drivers/usb/gadget/function/f_phonet.c
+++ b/drivers/usb/gadget/function/f_phonet.c
@@ -571,7 +571,6 @@ err_req:
 for (i = 0; i  phonet_rxq_size  fp-out_reqv[i]; i++)
 usb_ep_free_request(fp-out_ep, fp-out_reqv[i]);
 err:
-usb_free_all_descriptors(f);
 if (fp-out_ep)
 fp-out_ep-driver_data = NULL;
 if (fp-in_ep)
diff --git a/drivers/usb/gadget/function/f_rndis.c
b/drivers/usb/gadget/function/f_rndis.c
index ddb09dc..2f0517f 100644
--- a/drivers/usb/gadget/function/f_rndis.c
+++ b/drivers/usb/gadget/function/f_rndis.c
@@ -803,7 +803,7 @@ rndis_bind(struct usb_configuration *c, struct
usb_function *f)
 if (rndis-manufacturer  rndis-vendorID 
 rndis_set_param_vendor(rndis-config, rndis-vendorID,
rndis-manufacturer))
-goto fail;
+goto fail_free_descs;

 /* NOTE:  all that is done without knowing or caring about
  * the network link ... which is unavailable to this code
@@ -817,10 +817,11 @@ rndis_bind(struct usb_configuration *c, struct
usb_function *f)
 rndis-notify-name);
 return 0;

+fail_free_descs:
+usb_free_all_descriptors(f);
 fail:
 kfree(f-os_desc_table);
 f-os_desc_n = 0;
-usb_free_all_descriptors(f);

 if (rndis-notify_req) {
 kfree(rndis-notify_req-buf);
diff --git a/drivers/usb/gadget/function/f_subset.c
b/drivers/usb/gadget/function/f_subset.c
index 1ea8baf..e3dfa67 100644
--- a/drivers/usb/gadget/function/f_subset.c
+++ b/drivers/usb/gadget/function/f_subset.c
@@ -380,7 +380,6 @@ geth_bind(struct usb_configuration *c, struct
usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 /* we might as well release our claims on endpoints */
 if (geth-port.out_ep)
 geth-port.out_ep-driver_data = NULL;
diff --git a/drivers/usb/gadget/function/f_uac2.c
b/drivers/usb/gadget/function/f_uac2.c
index 3ed89ec..b45c39c 

Re: Subject: [PATCH] usb: gadget: function: Remove redundant usb_free_all_descriptors

[Robert Baldyga]

Hi,

Subject:  at the beginning of your email subject looks unnecessary.

When you're sending next version of your patch, you should add subject
prefix [PATCH vN], when N is number of version (eg. [PATCH v2]). See
Documentation/SubmittingPatches.
('git format-patch --subject-prefix' is helpful).

On 10/13/2014 11:35 AM, pavi1729 Sid wrote:
 Removed the usb_free_all_descriptors call in *_bind functions
 as this call is already present in usb_assign_descriptors.
 usb_assign_descriptors is the only call where usb descriptor
 allocation happens, also in case of error freeing of the
 allocated memory takes place in the same call. Hence the
 call in the *_bind functions are redundant.
 Also the presence of usb_free_all_descriptors in the *_bind
 functions might result in double-free corruption of the
 allocated mmeory.

s/mmeory/memory

 
 Signed-off-by: Pavitrakumar Managutte pavitra1...@gmail.com
 ---
  drivers/usb/gadget/function/f_eem.c|  1 -
  drivers/usb/gadget/function/f_hid.c|  7 +++
  drivers/usb/gadget/function/f_ncm.c|  1 -
  drivers/usb/gadget/function/f_phonet.c |  1 -
  drivers/usb/gadget/function/f_rndis.c  |  5 +++--
  drivers/usb/gadget/function/f_subset.c |  1 -
  drivers/usb/gadget/function/f_uac2.c   | 10 ++
  7 files changed, 12 insertions(+), 14 deletions(-)

There is another one usb function which needs to be fixed this way:
drivers/usb/gadget/function/f_obex.c

 
 diff --git a/drivers/usb/gadget/function/f_eem.c
 b/drivers/usb/gadget/function/f_eem.c
 index 4d8b236..c9e90de 100644
 --- a/drivers/usb/gadget/function/f_eem.c
 +++ b/drivers/usb/gadget/function/f_eem.c
 @@ -325,7 +325,6 @@ static int eem_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;
 
  fail:
 -usb_free_all_descriptors(f);
  if (eem-port.out_ep)
  eem-port.out_ep-driver_data = NULL;
  if (eem-port.in_ep)
 diff --git a/drivers/usb/gadget/function/f_hid.c
 b/drivers/usb/gadget/function/f_hid.c
 index a95290a..c36de0c 100644
 --- a/drivers/usb/gadget/function/f_hid.c
 +++ b/drivers/usb/gadget/function/f_hid.c
 @@ -621,12 +621,14 @@ static int __init hidg_bind(struct
 usb_configuration *c, struct usb_function *f)
  dev = MKDEV(major, hidg-minor);
  status = cdev_add(hidg-cdev, dev, 1);
  if (status)
 -goto fail;
 +goto fail_free_descs;
 
  device_create(hidg_class, NULL, dev, NULL, %s%d, hidg, hidg-minor);
 
  return 0;
 
 +fail_free_descs:
 +usb_free_all_descriptors(f);
  fail:
  ERROR(f-config-cdev, hidg_bind FAILED\n);
  if (hidg-req != NULL) {
 @@ -635,7 +637,6 @@ fail:
  usb_ep_free_request(hidg-in_ep, hidg-req);
  }
 
 -usb_free_all_descriptors(f);
  return status;
  }
 
 @@ -652,8 +653,6 @@ static void hidg_unbind(struct usb_configuration
 *c, struct usb_function *f)
  kfree(hidg-req-buf);
  usb_ep_free_request(hidg-in_ep, hidg-req);
 
 -usb_free_all_descriptors(f);
 -

Why usb_free_all_descriptors() removed from here?

  kfree(hidg-report_desc);
  kfree(hidg);
  }
 diff --git a/drivers/usb/gadget/function/f_ncm.c
 b/drivers/usb/gadget/function/f_ncm.c
 index bcdc882..38a9279 100644
 --- a/drivers/usb/gadget/function/f_ncm.c
 +++ b/drivers/usb/gadget/function/f_ncm.c
 @@ -1453,7 +1453,6 @@ static int ncm_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;
 
  fail:
 -usb_free_all_descriptors(f);
  if (ncm-notify_req) {
  kfree(ncm-notify_req-buf);
  usb_ep_free_request(ncm-notify, ncm-notify_req);
 diff --git a/drivers/usb/gadget/function/f_phonet.c
 b/drivers/usb/gadget/function/f_phonet.c
 index b9cfc15..74ddcac 100644
 --- a/drivers/usb/gadget/function/f_phonet.c
 +++ b/drivers/usb/gadget/function/f_phonet.c
 @@ -571,7 +571,6 @@ err_req:
  for (i = 0; i  phonet_rxq_size  fp-out_reqv[i]; i++)
  usb_ep_free_request(fp-out_ep, fp-out_reqv[i]);
  err:
 -usb_free_all_descriptors(f);

What if usb_ep_alloc_request() fails?
Consider calling usb_free_all_descriptors() under label err_req.

  if (fp-out_ep)
  fp-out_ep-driver_data = NULL;
  if (fp-in_ep)
 diff --git a/drivers/usb/gadget/function/f_rndis.c
 b/drivers/usb/gadget/function/f_rndis.c
 index ddb09dc..2f0517f 100644
 --- a/drivers/usb/gadget/function/f_rndis.c
 +++ b/drivers/usb/gadget/function/f_rndis.c
 @@ -803,7 +803,7 @@ rndis_bind(struct usb_configuration *c, struct
 usb_function *f)
  if (rndis-manufacturer  rndis-vendorID 
  rndis_set_param_vendor(rndis-config, rndis-vendorID,
 rndis-manufacturer))
 -goto fail;
 +goto fail_free_descs;
 
  /* NOTE:  all that is done without knowing or caring about
   * the network link ... which is unavailable to this code
 @@ -817,10 +817,11 @@ rndis_bind(struct usb_configuration *c, struct
 usb_function *f)
  rndis-notify-name);
  return 0;
 
 +fail_free_descs:
 +usb_free_all_descriptors(f);
  fail

Re: Subject: [PATCH] usb: gadget: function: Remove redundant usb_free_all_descriptors

[pavi1729 Sid]

On Mon, Oct 13, 2014 at 6:55 PM, Robert Baldyga r.bald...@samsung.com wrote:
 Hi,

 Subject:  at the beginning of your email subject looks unnecessary.

 When you're sending next version of your patch, you should add subject
 prefix [PATCH vN], when N is number of version (eg. [PATCH v2]). See
 Documentation/SubmittingPatches.
 ('git format-patch --subject-prefix' is helpful).

 On 10/13/2014 11:35 AM, pavi1729 Sid wrote:
 Removed the usb_free_all_descriptors call in *_bind functions
 as this call is already present in usb_assign_descriptors.
 usb_assign_descriptors is the only call where usb descriptor
 allocation happens, also in case of error freeing of the
 allocated memory takes place in the same call. Hence the
 call in the *_bind functions are redundant.
 Also the presence of usb_free_all_descriptors in the *_bind
 functions might result in double-free corruption of the
 allocated mmeory.

 s/mmeory/memory
Will fix it.


 Signed-off-by: Pavitrakumar Managutte pavitra1...@gmail.com
 ---
  drivers/usb/gadget/function/f_eem.c|  1 -
  drivers/usb/gadget/function/f_hid.c|  7 +++
  drivers/usb/gadget/function/f_ncm.c|  1 -
  drivers/usb/gadget/function/f_phonet.c |  1 -
  drivers/usb/gadget/function/f_rndis.c  |  5 +++--
  drivers/usb/gadget/function/f_subset.c |  1 -
  drivers/usb/gadget/function/f_uac2.c   | 10 ++
  7 files changed, 12 insertions(+), 14 deletions(-)

 There is another one usb function which needs to be fixed this way:
 drivers/usb/gadget/function/f_obex.c
Will fix it.


 diff --git a/drivers/usb/gadget/function/f_eem.c
 b/drivers/usb/gadget/function/f_eem.c
 index 4d8b236..c9e90de 100644
 --- a/drivers/usb/gadget/function/f_eem.c
 +++ b/drivers/usb/gadget/function/f_eem.c
 @@ -325,7 +325,6 @@ static int eem_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;

  fail:
 -usb_free_all_descriptors(f);
  if (eem-port.out_ep)
  eem-port.out_ep-driver_data = NULL;
  if (eem-port.in_ep)
 diff --git a/drivers/usb/gadget/function/f_hid.c
 b/drivers/usb/gadget/function/f_hid.c
 index a95290a..c36de0c 100644
 --- a/drivers/usb/gadget/function/f_hid.c
 +++ b/drivers/usb/gadget/function/f_hid.c
 @@ -621,12 +621,14 @@ static int __init hidg_bind(struct
 usb_configuration *c, struct usb_function *f)
  dev = MKDEV(major, hidg-minor);
  status = cdev_add(hidg-cdev, dev, 1);
  if (status)
 -goto fail;
 +goto fail_free_descs;

  device_create(hidg_class, NULL, dev, NULL, %s%d, hidg, hidg-minor);

  return 0;

 +fail_free_descs:
 +usb_free_all_descriptors(f);
  fail:
  ERROR(f-config-cdev, hidg_bind FAILED\n);
  if (hidg-req != NULL) {
 @@ -635,7 +637,6 @@ fail:
  usb_ep_free_request(hidg-in_ep, hidg-req);
  }

 -usb_free_all_descriptors(f);
  return status;
  }

 @@ -652,8 +653,6 @@ static void hidg_unbind(struct usb_configuration
 *c, struct usb_function *f)
  kfree(hidg-req-buf);
  usb_ep_free_request(hidg-in_ep, hidg-req);

 -usb_free_all_descriptors(f);
 -

 Why usb_free_all_descriptors() removed from here?
My bad .. its not supposed to be in unbind function. Will fix it.

  kfree(hidg-report_desc);
  kfree(hidg);
  }
 diff --git a/drivers/usb/gadget/function/f_ncm.c
 b/drivers/usb/gadget/function/f_ncm.c
 index bcdc882..38a9279 100644
 --- a/drivers/usb/gadget/function/f_ncm.c
 +++ b/drivers/usb/gadget/function/f_ncm.c
 @@ -1453,7 +1453,6 @@ static int ncm_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;

  fail:
 -usb_free_all_descriptors(f);
  if (ncm-notify_req) {
  kfree(ncm-notify_req-buf);
  usb_ep_free_request(ncm-notify, ncm-notify_req);
 diff --git a/drivers/usb/gadget/function/f_phonet.c
 b/drivers/usb/gadget/function/f_phonet.c
 index b9cfc15..74ddcac 100644
 --- a/drivers/usb/gadget/function/f_phonet.c
 +++ b/drivers/usb/gadget/function/f_phonet.c
 @@ -571,7 +571,6 @@ err_req:
  for (i = 0; i  phonet_rxq_size  fp-out_reqv[i]; i++)
  usb_ep_free_request(fp-out_ep, fp-out_reqv[i]);
  err:
 -usb_free_all_descriptors(f);

 What if usb_ep_alloc_request() fails?
 Consider calling usb_free_all_descriptors() under label err_req.
Agreed. Will fix it.

  if (fp-out_ep)
  fp-out_ep-driver_data = NULL;
  if (fp-in_ep)
 diff --git a/drivers/usb/gadget/function/f_rndis.c
 b/drivers/usb/gadget/function/f_rndis.c
 index ddb09dc..2f0517f 100644
 --- a/drivers/usb/gadget/function/f_rndis.c
 +++ b/drivers/usb/gadget/function/f_rndis.c
 @@ -803,7 +803,7 @@ rndis_bind(struct usb_configuration *c, struct
 usb_function *f)
  if (rndis-manufacturer  rndis-vendorID 
  rndis_set_param_vendor(rndis-config, rndis-vendorID,
 rndis-manufacturer))
 -goto fail;
 +goto fail_free_descs;

  /* NOTE:  all that is done without knowing or caring about
   * the network link ... which is unavailable to this code
 @@ -817,10

[no subject]

[Personal Charity]

We have a private donation for you

--
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

[no subject]

[Christian Melki]

unsubscribe linux-usb--
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

[no subject]

[Christian Melki]

unsubscribe--
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

[no subject]

[®®®]

Sehr geehrte Begünstigte,

Sie haben als einzige Begünstigte der Summe von fünfhunderttausend Euro (€ 
500.000,00 Euro), die hier in WESTERN UNION OFFICE von der ONU Organisation für 
Sie hinterlegt ausgewählt wurde.

Bitte kontaktieren Sie uns für Ansprüche Email: wes_sp...@outlook.com

Kundendienst
Western Union Office®
--
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

[no subject]

[®®®]

Sehr geehrte Begünstigte,

Sie haben als einzige Begünstigte der Summe von fünfhunderttausend Euro (€ 
500.000,00 Euro), die hier in WESTERN UNION OFFICE von der ONU Organisation für 
Sie hinterlegt ausgewählt wurde.

Bitte kontaktieren Sie uns für Ansprüche Email: wes_sp...@outlook.com

Kundendienst
Western Union Office®
--
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

[no subject]

[®®®]

Sehr geehrte Begünstigte,

Sie haben als einzige Begünstigte der Summe von fünfhunderttausend Euro (€ 
500.000,00 Euro), die hier in WESTERN UNION OFFICE von der ONU Organisation für 
Sie hinterlegt ausgewählt wurde.

Bitte kontaktieren Sie uns für Ansprüche Email: wes_sp...@outlook.com

Kundendienst
Western Union Office®
--
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

[no subject]

[Thomas Schäfer]

 auth 9af38645 subscribe linux-usb tschae...@t-online.de
--
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 0/4] *** SUBJECT HERE ***

[Greg KH]

On Wed, Aug 20, 2014 at 07:30:58AM +0300, Valentina Manea wrote:
 After migrating userspace code to libudev, converting usbip-host
 to a device driver and various bug fixes and enhancements, USB/IP
 is fully functional and can be moved out of staging.
 
 This patch series moves it as following:
 * userspace code to tools/usb/usbip
 * kernel code to drivers/usb/usbip
 
 A warning generated in the kernel code is also solved and an entry
 in MAINTAINERS file is created for this driver.

Looks good, all now queued up, thanks.

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 0/4] *** SUBJECT HERE ***

[Valentina Manea]

After migrating userspace code to libudev, converting usbip-host
to a device driver and various bug fixes and enhancements, USB/IP
is fully functional and can be moved out of staging.

This patch series moves it as following:
* userspace code to tools/usb/usbip
* kernel code to drivers/usb/usbip

A warning generated in the kernel code is also solved and an entry
in MAINTAINERS file is created for this driver.

Valentina Manea (4):
  usbip: move usbip userspace code out of staging
  usbip: move usbip kernel code out of staging
  usbip: remove struct usb_device_id table
  MAINTAINERS: Add an entry for USB/IP driver

 MAINTAINERS|  8 +++
 drivers/staging/Kconfig|  2 --
 drivers/staging/Makefile   |  1 -
 drivers/usb/Kconfig|  2 ++
 drivers/usb/Makefile   |  2 ++
 drivers/{staging = usb}/usbip/Kconfig |  0
 drivers/{staging = usb}/usbip/Makefile|  0
 drivers/{staging = usb}/usbip/README  |  0
 drivers/{staging = usb}/usbip/stub.h  |  0
 drivers/{staging = usb}/usbip/stub_dev.c  | 27 --
 drivers/{staging = usb}/usbip/stub_main.c |  0
 drivers/{staging = usb}/usbip/stub_rx.c   |  0
 drivers/{staging = usb}/usbip/stub_tx.c   |  0
 drivers/{staging = usb}/usbip/usbip_common.c  |  0
 drivers/{staging = usb}/usbip/usbip_common.h  |  2 +-
 drivers/{staging = usb}/usbip/usbip_event.c   |  0
 drivers/{staging = usb}/usbip/usbip_protocol.txt  |  0
 drivers/{staging = usb}/usbip/vhci.h  |  0
 drivers/{staging = usb}/usbip/vhci_hcd.c  |  0
 drivers/{staging = usb}/usbip/vhci_rx.c   |  0
 drivers/{staging = usb}/usbip/vhci_sysfs.c|  0
 drivers/{staging = usb}/usbip/vhci_tx.c   |  0
 .../usbip/uapi = include/uapi/linux}/usbip.h  |  0
 .../usbip/userspace = tools/usb/usbip}/.gitignore |  0
 .../usbip/userspace = tools/usb/usbip}/AUTHORS|  0
 .../usbip/userspace = tools/usb/usbip}/COPYING|  0
 .../usbip/userspace = tools/usb/usbip}/INSTALL|  0
 .../userspace = tools/usb/usbip}/Makefile.am  |  0
 .../usbip/userspace = tools/usb/usbip}/README |  0
 .../usbip/userspace = tools/usb/usbip}/autogen.sh |  0
 .../usbip/userspace = tools/usb/usbip}/cleanup.sh |  0
 .../userspace = tools/usb/usbip}/configure.ac |  0
 .../userspace = tools/usb/usbip}/doc/usbip.8  |  0
 .../userspace = tools/usb/usbip}/doc/usbipd.8 |  0
 .../usb/usbip}/libsrc/Makefile.am  |  0
 .../userspace = tools/usb/usbip}/libsrc/list.h|  0
 .../userspace = tools/usb/usbip}/libsrc/names.c   |  0
 .../userspace = tools/usb/usbip}/libsrc/names.h   |  0
 .../usb/usbip}/libsrc/sysfs_utils.c|  0
 .../usb/usbip}/libsrc/sysfs_utils.h|  0
 .../usb/usbip}/libsrc/usbip_common.c   |  0
 .../usb/usbip}/libsrc/usbip_common.h   |  0
 .../usb/usbip}/libsrc/usbip_host_driver.c  |  0
 .../usb/usbip}/libsrc/usbip_host_driver.h  |  0
 .../usb/usbip}/libsrc/vhci_driver.c|  0
 .../usb/usbip}/libsrc/vhci_driver.h|  0
 .../userspace = tools/usb/usbip}/src/Makefile.am  |  0
 .../userspace = tools/usb/usbip}/src/usbip.c  |  0
 .../userspace = tools/usb/usbip}/src/usbip.h  |  0
 .../usb/usbip}/src/usbip_attach.c  |  0
 .../userspace = tools/usb/usbip}/src/usbip_bind.c |  0
 .../usb/usbip}/src/usbip_detach.c  |  0
 .../userspace = tools/usb/usbip}/src/usbip_list.c |  0
 .../usb/usbip}/src/usbip_network.c |  0
 .../usb/usbip}/src/usbip_network.h |  0
 .../userspace = tools/usb/usbip}/src/usbip_port.c |  0
 .../usb/usbip}/src/usbip_unbind.c  |  0
 .../userspace = tools/usb/usbip}/src/usbipd.c |  0
 .../userspace = tools/usb/usbip}/src/utils.c  |  0
 .../userspace = tools/usb/usbip}/src/utils.h  |  0
 60 files changed, 13 insertions(+), 31 deletions(-)
 rename drivers/{staging = usb}/usbip/Kconfig (100%)
 rename drivers/{staging = usb}/usbip/Makefile (100%)
 rename drivers/{staging = usb}/usbip/README (100%)
 rename drivers/{staging = usb}/usbip/stub.h (100%)
 rename drivers/{staging = usb}/usbip/stub_dev.c (90%)
 rename drivers/{staging = usb}/usbip/stub_main.c (100%)
 rename drivers/{staging = usb}/usbip/stub_rx.c (100%)
 rename drivers/{staging = usb}/usbip/stub_tx.c (100%)
 rename drivers/{staging = usb}/usbip/usbip_common.c (100%)
 rename drivers/{staging = usb}/usbip/usbip_common.h (99%)
 rename drivers/{staging = usb}/usbip/usbip_event.c (100%)
 rename drivers/{staging = usb}/usbip/usbip_protocol.txt (100%)
 rename drivers/{staging = usb}/usbip/vhci.h (100%)
 rename drivers/{staging = usb}/usbip/vhci_hcd.c (100%)
 rename drivers/{staging = usb}/usbip/vhci_rx.c (100%)
 rename drivers/{staging = usb}/usbip/vhci_sysfs.c (100%)
 

[no subject]

[WESTERN UNION]

-- 
Attention

Customer, $200,000,00 USD was won by your email from
the Western Union.Please contact Mr Morris Smith so that your fund will
be remitted to you through Western Union Transfer

Regard
Mr Morris Smith
+2348117653376
--
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 v3 0/2] Fix subject line

[Davidlohr Bueso]

On Mon, 2014-06-16 at 00:28 +0400, Wahib wrote:
 Hi Davidlohr!
 
 Don't worry. I am not discouraged. :)
 
 I understand your concern that the patch feels superficial. It's what the task
 asked us to do. I suspect the author(s) of the Eudyptula Challenge designed
 this task to get us involved with the Linux kernel community.

If you feel you actually learn something by doing the Eudyptula
Challenge, then good for you, and by all means continue doing so. As I
mentioned, I know almost zero about it, but can say for sure that
cleanups alone won't get you very far in the community and you will
probably get bored sooner or later -- which is unfortunate as kernel
hacking fascinating.

 
 I have been looking for a bug in 'usbip' to bundle with my patch. The only bug
 that I could find (as of 16-Jun-2014) on bugzilla.kernel.org related
 to 'usbip' is Bug 77191.
 
 Bug 77191 - ftdi-sio (usbserial) over usbip hung after disconnect while in use
 (https://bugzilla.kernel.org/show_bug.cgi?id=77191)
 
 Sadly the bug doesn't seem to be newbie friendly as it requires special setup
 to reproduce and requires the developer to know about the intricacies of the
 'usbip' subsystem. I understand that people commiting their specialized
 knowledge is how the kernel development actually works. But USB is not my
 speciality (yet).
 
 Could you point me to more beginner friendly bugs which aren't superficial 
 code
 cleanups?

There are plenty of bugs out there, and not so hard to find -- just push
some module/filesystem/subsystem/testcase hard enough to make it do
things it shouldn't. Run linux-next on trinity and fix/report the bugs,
etc.

imho testing and reading other people's patches is perhaps the best way
to do useful things, get acquainted with the code and get experience
with lkml and the process behind kernel development.

 Can I bundle fixes to subsystems other than 'usbip' with the code cleanup 
 patch
 for 'usbip'?

Probably not, unless it's a tree-wide change.

Hope this helps,
Davidlohr

--
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 v3 0/2] Fix subject line

[Wahib]

Hi Davidlohr!

Don't worry. I am not discouraged. :)

I understand your concern that the patch feels superficial. It's what the task
asked us to do. I suspect the author(s) of the Eudyptula Challenge designed
this task to get us involved with the Linux kernel community.

I have been looking for a bug in 'usbip' to bundle with my patch. The only bug
that I could find (as of 16-Jun-2014) on bugzilla.kernel.org related
to 'usbip' is Bug 77191.

Bug 77191 - ftdi-sio (usbserial) over usbip hung after disconnect while in use
(https://bugzilla.kernel.org/show_bug.cgi?id=77191)

Sadly the bug doesn't seem to be newbie friendly as it requires special setup
to reproduce and requires the developer to know about the intricacies of the
'usbip' subsystem. I understand that people commiting their specialized
knowledge is how the kernel development actually works. But USB is not my
speciality (yet).

Could you point me to more beginner friendly bugs which aren't superficial code
cleanups?

Can I bundle fixes to subsystems other than 'usbip' with the code cleanup patch
for 'usbip'?

Regards,
Wahib

On Fri, Jun 13, 2014 at 12:25 AM, Davidlohr Bueso davidl...@hp.com wrote:
 On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
 Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.

 Sorry but unless bundled with something more meaningful, I really don't
 see the value in these changes. I certainly don't want to discourage
 folks or anything, but just testing other patches is a lot more helpful
 than this.

 I haven't followed much about the Eudyptula Challenge, but I hope other
 assignments are more involved than this.

 Thanks,
 Davidlohr

--
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

[no subject]

[Mrs Teresa AU]

Although you might be nervous about my e-mail as we have not met  
before. My name is Mrs Teresa Au, I work with HSBC Hong Kong; there is  
a sum of USD$23,200,000.00 business proposal I want to share with you.  
It is absolutely risk  free; if you are interested send me a reply to  
my private e-mail below : mrs_t...@126.com


Best Regards,
Email: mrs_t...@126.com
Mrs Teresa Au.







Provincia di Treviso - http://www.provincia.treviso.it

--
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

Fix subject line

[Wahib Faizi]

Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.

v3: Shorten subject line, as suggested by
Greg Kroah-Hartman gre...@linuxfoundation.org,
Joe Perches j...@perches.com
 
v2: Split patch into logical chunks, as suggested by
Greg Kroah-Hartman gre...@linuxfoundation.org

--
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 v3 0/2] Fix subject line

[Wahib Faizi]

Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.

v3: Shorten subject line, as suggested by 
Greg Kroah-Hartman gre...@linuxfoundation.org,
Joe Perches j...@perches.com

v2: Split patch into logical chunks, as suggested by 
Greg Kroah-Hartman gre...@linuxfoundation.org

--
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 v3 0/2] Fix subject line

[Davidlohr Bueso]

On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
 Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.

Sorry but unless bundled with something more meaningful, I really don't
see the value in these changes. I certainly don't want to discourage
folks or anything, but just testing other patches is a lot more helpful
than this. 

I haven't followed much about the Eudyptula Challenge, but I hope other
assignments are more involved than this.

Thanks,
Davidlohr

--
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 v3 0/2] Fix subject line

[Greg Kroah-Hartman]

On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote:
 On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
  Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.
 
 Sorry but unless bundled with something more meaningful, I really don't
 see the value in these changes. I certainly don't want to discourage
 folks or anything, but just testing other patches is a lot more helpful
 than this. 

When the staging code is still needing basic fixes like this, it is
meaningful to do patches that clean up stuff like this.  That's what
the staging tree is for.

thanks,

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

Re: [PATCH v3 0/2] Fix subject line

[Davidlohr Bueso]

On Thu, 2014-06-12 at 13:35 -0700, Greg Kroah-Hartman wrote:
 On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote:
  On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
   Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.
  
  Sorry but unless bundled with something more meaningful, I really don't
  see the value in these changes. I certainly don't want to discourage
  folks or anything, but just testing other patches is a lot more helpful
  than this. 
 
 When the staging code is still needing basic fixes like this, it is
 meaningful to do patches that clean up stuff like this.  That's what
 the staging tree is for.

Sure, but making checkpatch happy just to make checkpatch happy isn't
a good justification, even for staging. Patch 1 does have value in that
it helps avoid silly bugs, but take patch 2/2, we end-up saving just a
few spaces... Anyways, just my 2 cents.

Thanks,
Davidlohr

--
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 v3 0/2] Fix subject line

[Dan Carpenter]

On Thu, Jun 12, 2014 at 01:48:38PM -0700, Davidlohr Bueso wrote:
 On Thu, 2014-06-12 at 13:35 -0700, Greg Kroah-Hartman wrote:
  On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote:
   On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
Fix coding style issues detected by checkpatch.pl in 
usbip_host_driver.c.
   
   Sorry but unless bundled with something more meaningful, I really don't
   see the value in these changes. I certainly don't want to discourage
   folks or anything, but just testing other patches is a lot more helpful
   than this. 
  
  When the staging code is still needing basic fixes like this, it is
  meaningful to do patches that clean up stuff like this.  That's what
  the staging tree is for.
 
 Sure, but making checkpatch happy just to make checkpatch happy isn't
 a good justification, even for staging.

It actually is.  Fighting against checkpatch is a losers battle.  Our
way more efficient.

1) We do need to fix this checkpatch warning before it moves out of
   staging.
2) NAKing patches is actually a lot of stress for everyone.  It stresses
   out submitters and drives them away.  It stresses out the
   maintainers because we feel bad.  That stress is bad when it is
   pointless.
3) This patch is ok.
4) If we don't apply this patch then someone else will send the exact
   same patch or something worse until we apply something.
5) The v3 of this patch takes under 30 seconds to review and apply.
6) Newbies feel happy when their patch gets merged and that is good.

The other thing is that if you start asking Is this patch meaningful
then it makes applying any patch into a big question about meaning and
it tires you out.

In staging we have clear rules for when a patch is going to be applied
and everyone understands the rules.  It means that if Greg is traveling
then you know which patches he is going to apply in what order and life
is easier because it is more predictable.

regards,
dan carpenter

--
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

[no subject]

[Michael Durkin]

Im not sure if im even looking in the right resource ...

I have a Fresco Logic USB3/2 to VGA adapter and im not sure if there
is support for it in the kernel ...

Vender id is 1d5c and the producet is 2000
--
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

[no subject]

[lin du]

subscribe linux-usb
--
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

[no subject]

[KELLY CRISTINA D ANGELO]

Bestauml;tigen Sie Ihre 500,000,00 Euro
--
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

[no subject]

[ADELIA SOARES RIBAS]

Claim your 500,000,00 Euros
--
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

[no subject]

[Marcos Antonio da Silva]

Optimieren Sie Ihren 500,000,00 Euro
--
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

[no subject]

[Christian organization]

Good day,

if you are a dedicated christian,contact us for your christian loan
organization, via email;info.finance...@yahoo.com



--
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

[no subject]

[Kasberger Andreas]

unsubscribe linux-usb --
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

[no subject]

[Sebastan Weiß]

auth 3f2b0701 subscribe linux-usb \
stagepiker...@gmail.com

--
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

[no subject]

[Western Union Office ©]

Congratulation !! Confirm your 500,000,00 Euros. Contact claims office via : 
claimsoffic...@yeah.net
--
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

[no subject]

[Marco Zamponi]

Hello!
I have a question regarding the user space testapplication for FunctionFS
(http://stuff.mit.edu/afs/sipb/contrib/linux/tools/usb/ffs-test.c).
The struct descriptors that contains the header and the fs and hs descriptors
has only interface and endpoint descriptors. Those are written to ep0.
I understand that device and config descriptor are added by the FunctionFS
module?
I tried adding them to the descriptor struct and increasing fs_count and
hs_count in the header filed by 2, but the write() on ep0 then returns -1:
ffs-test: crit: ep0: write: descriptors: (-22) Invalid argument.

Is it possible to pass my own device and config descriptor to the module or
do I have to patch the module?
Thanks!
--
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: [RFCv5-corrected subject] USB: kill #undef VERBOSE_DEBUG

[Oliver Neukum]

On Sat, 2013-11-16 at 06:26 +0900, Greg KH wrote:
 On Fri, Nov 15, 2013 at 03:36:53PM +0100, oli...@neukum.org wrote:
  From: Oliver Neukum oneu...@suse.de
  
  It is useless now. Straight removal.
  
  Signed-off-by: Oliver Neukum oneu...@suse.de
 
 Ok, I think these have all moved beyond RFC material, right?  Care to
 resend the series as something you want me to apply after 3.13-rc1 is
 out?  (that's when I can apply them, no need for you to wait until then
 if you don't want to, I'll queue them up internally.)

Very well, I've fixed Alan's last issue and will send it out.

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

[RFCv5-corrected subject] USB: kill #undef VERBOSE_DEBUG

[oliver]

From: Oliver Neukum oneu...@suse.de

It is useless now. Straight removal.

Signed-off-by: Oliver Neukum oneu...@suse.de
---
 drivers/usb/host/ehci-hcd.c | 1 -
 drivers/usb/host/fotg210-hcd.c  | 1 -
 drivers/usb/host/fusbh200-hcd.c | 1 -
 drivers/usb/host/ohci-hcd.c | 2 --
 4 files changed, 5 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 1e21a36..4711427 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -71,7 +71,6 @@
 static const char  hcd_name [] = ehci_hcd;
 
 
-#undef VERBOSE_DEBUG
 #undef EHCI_URB_TRACE
 
 /* magic numbers that can affect system performance */
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 070582b..97d6939 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -56,7 +56,6 @@
 
 static const char  hcd_name[] = fotg210_hcd;
 
-#undef VERBOSE_DEBUG
 #undef FOTG210_URB_TRACE
 
 #define FOTG210_STATS
diff --git a/drivers/usb/host/fusbh200-hcd.c b/drivers/usb/host/fusbh200-hcd.c
index d5e379b..9ea85b6 100644
--- a/drivers/usb/host/fusbh200-hcd.c
+++ b/drivers/usb/host/fusbh200-hcd.c
@@ -57,7 +57,6 @@
 
 static const char  hcd_name [] = fusbh200_hcd;
 
-#undef VERBOSE_DEBUG
 #undef FUSBH200_URB_TRACE
 
 /* magic numbers that can affect system performance */
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index de0e3e4..c8e0e76 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -51,8 +51,6 @@
 
 /*-*/
 
-#undef OHCI_VERBOSE_DEBUG  /* not always helpful */
-
 /* For initializing controller (mask in an HCFS mode too) */
 #defineOHCI_CONTROL_INIT   OHCI_CTRL_CBSR
 #defineOHCI_INTR_INIT \
-- 
1.8.3.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: [RFCv5-corrected subject] USB: kill #undef VERBOSE_DEBUG

[Greg KH]

On Fri, Nov 15, 2013 at 03:36:53PM +0100, oli...@neukum.org wrote:
 From: Oliver Neukum oneu...@suse.de
 
 It is useless now. Straight removal.
 
 Signed-off-by: Oliver Neukum oneu...@suse.de

Ok, I think these have all moved beyond RFC material, right?  Care to
resend the series as something you want me to apply after 3.13-rc1 is
out?  (that's when I can apply them, no need for you to wait until then
if you don't want to, I'll queue them up internally.)

thanks,

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

(no subject)

[Carolina Andrea Puentes Arriagada]

Helló, van szüksége sürgős kölcsön néhány korai karácsonyi és hálaadás 
vásárlás a barátod, és szeretett egy, akkor is, azért vagyunk itt, hogy 
segítsen ki, a Jennifer pénzügyi cég is ad ki hitelt, a kamat, ami olyan 
alacsony, mint 3 százalék, így üzlet elején és a lehető legjobb ajándék 
a family.Contact minket ma: jenifer.financia...@gmail.com


Teljes neve:
ország:
Telefonszám:
Havi jövedelem:
Hitel összege:
Hitel Időtartam:

Kérjük, vegye fel Xmas Hitel és a Get Back To Me Oké.
Mrs.Jennifer.
--
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