Re: usb: chipidea: hdc: kernel panic during shutdown
On Thu, Aug 25, 2016 at 07:06:12AM +0200, Stefan Wahren wrote:
> Hi Alan,
>
> > Alan Stern hat am 24. August 2016 um 20:55
> > geschrieben:
> >
> >
> > On Wed, 24 Aug 2016, Stefan Wahren wrote:
> >
> > > Hi,
> > >
> > > [add Li Jun to CC]
> > >
> > > > Alan Stern hat am 24. August 2016 um 15:45
> > > > geschrieben:
> > > >
> > > >
> > > > On Wed, 24 Aug 2016, Peter Chen wrote:
> > > >
> > > > > On Tue, Aug 23, 2016 at 09:17:02PM +0200, Stefan Wahren wrote:
> > > > > > Hi,
> > > > > >
> > > > > > i'm using a iMX233-OLinuXino board and the kernel panics during
> > > > > > shutdown
> > > > > > with
> > > > > > 4.8.0-rc2-next-20160819:
> > > > > >
> > > > > > [ 420.04] ci_hdrc ci_hdrc.0: remove, state 1
> > > > > > [ 420.05] usb usb1: USB disconnect, device number 1
> > > > > > [ 420.06] usb 1-1: USB disconnect, device number 2
> > > > > > [ 420.06] usb 1-1.1: USB disconnect, device number 3
> > > > > > [ 420.09] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx'
> > > > > > usb-ci_hdrc.0-1.1,
> > > > > > smsc95xx USB 2.0 Ethernet
> > > > > > [ 420.29] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
> > > > > > [ 420.30] Unable to handle kernel NULL pointer dereference at
> > > > > > virtual
> > > > > > address 0118
> > > > > > [ 420.30] pgd = c2ea4000
> > > > > > [ 420.30] [0118] *pgd=
> > > > > > [ 420.30] Internal error: Oops: 5 [#1] ARM
> > > > > > [ 420.30] Modules linked in:
> > > > > > [ 420.30] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted
> > > > > > 4.8.0-rc2-next-20160819 #1
> > > > > > [ 420.30] Hardware name: Freescale MXS (Device Tree)
> > > > > > [ 420.30] task: c349 task.stack: c348e000
> > > > > > [ 420.30] PC is at usb_hcd_irq+0x0/0x34
> > > > > > [ 420.30] LR is at ci_irq+0x58/0x12c
> > > >
> > > > > I am afraid the hcd is freed before the interrupt triggered. Would you
> > > > > please try below changes:
> > > > >
> > > > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> > > > > index 96ae695..61237a9 100644
> > > > > --- a/drivers/usb/chipidea/host.c
> > > > > +++ b/drivers/usb/chipidea/host.c
> > > > > @@ -103,7 +103,7 @@ static const struct ehci_driver_overrides
> > > > > ehci_ci_overrides = {
> > > > > static irqreturn_t host_irq(struct ci_hdrc *ci)
> > > > > {
> > > > > - return usb_hcd_irq(ci->irq, ci->hcd);
> > > > > + return ci->hcd ? usb_hcd_irq(ci->irq, ci->hcd) : IRQ_NONE;
> > > > > }
> > > >
> > > > This should not be needed. Instead, the driver should make sure that
> > > > the interrupt handler has been fully unregistered before the hcd is
> > > > deallocated.
> > >
> > > according to ci_hdrc_probe() from the chipidea core the IRQ seems to be
> > > requested via devm_request_irq() with the flag IRQF_SHARED.
> > >
> > > I have the suspicion the following commit triggers the kernel panic:
> > >
> > > 43a404577a93 ("usb: chipidea: host: set host to be null after hcd is
> > > freed")
> >
> > No, that's not the cause. Without that commit, you would try to access
> > deallocated memory instead of trying to dereference a NULL pointer, but
> > the kernel would still oops.
> >
> > Instead, how about setting ci->role to CI_ROLE_END and then calling
> > synchronize_irq(ci->irq) in host_stop(), before the usb_put_hcd()?
>
> i tried the following patch:
>
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
>
> if (hcd) {
> usb_remove_hcd(hcd);
> + ci_role_stop(ci);
> + synchronize_irq(ci->irq);
Would you please just add below line to see if this problem can be
fixed?
+ ci->role = CI_ROLE_END;
When ci->role is CI_ROLE_END, neither host nor device interrupt handler
will run.
What is your controller role? (dr_mode = host, peripheral or otg)?
Besides, you would please add below line at core.c to show what
interrupt occurs at that time:
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index b5c155b..e6b8a7e 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -596,6 +596,12 @@ static irqreturn_t ci_irq(int irq, void *data)
/* Handle device/host interrupt */
if (ci->role != CI_ROLE_END)
ret = ci_role(ci)->irq(ci);
+ else
+ dev_info(ci->dev, "otgsc:0x%x, usbsts:0x%x\n",
+ hw_read_otgsc(ci, ~0),
+ hw_read_intr_status(ci) &
hw_read_intr_enable(ci)
+ );
+
return ret;
}
> usb_put_hcd(hcd);
> if (ci->platdata->reg_vbus && !ci_otg_is_fsm_mode(ci) &&
> (ci->platdata->flags & CI_HDRC_TURN_VBUS_EARLY_ON))
>
> the i get the following during shutdown:
The reason for this is the host_stop is re-entered.
Peter
>
> [ 102.17] ci_hdrc ci_hdrc.0: remove, state 1
Re: usb: chipidea: hdc: kernel panic during shutdown
Am 25.08.2016 um 08:44 schrieb Peter Chen:
> On Thu, Aug 25, 2016 at 07:06:12AM +0200, Stefan Wahren wrote:
>> Hi Alan,
>>
>> i tried the following patch:
>> --- a/drivers/usb/chipidea/host.c
>> +++ b/drivers/usb/chipidea/host.c
>> @@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
>>
>> if (hcd) {
>> usb_remove_hcd(hcd);
>> + ci_role_stop(ci);
>> + synchronize_irq(ci->irq);
> Would you please just add below line to see if this problem can be
> fixed?
> + ci->role = CI_ROLE_END;
>
> When ci->role is CI_ROLE_END, neither host nor device interrupt handler
> will run.
I would add this before synchronize_irq() as Alan suggested.
>
> What is your controller role? (dr_mode = host, peripheral or otg)?
I'm using the unmodified arch/arm/boot/dts/imx23-olinuxino.dts so:
dr_mode = host
> Besides, you would please add below line at core.c to show what
> interrupt occurs at that time:
>
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index b5c155b..e6b8a7e 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -596,6 +596,12 @@ static irqreturn_t ci_irq(int irq, void *data)
> /* Handle device/host interrupt */
> if (ci->role != CI_ROLE_END)
> ret = ci_role(ci)->irq(ci);
> + else
> + dev_info(ci->dev, "otgsc:0x%x, usbsts:0x%x\n",
> + hw_read_otgsc(ci, ~0),
> + hw_read_intr_status(ci) &
> hw_read_intr_enable(ci)
> + );
> +
>
> return ret;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] usb: dwc3: gadget: always decrement by 1
We need to decrement in both cases (enq > deq and enq < deq) Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 594e82595634..e4ef9ed1a143 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -884,12 +884,9 @@ static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep) return DWC3_TRB_NUM - 1; } - trbs_left = dep->trb_dequeue - dep->trb_enqueue; + trbs_left = dep->trb_dequeue - dep->trb_enqueue - 1; trbs_left &= (DWC3_TRB_NUM - 1); - if (dep->trb_dequeue < dep->trb_enqueue) - trbs_left--; - return trbs_left; } -- 2.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] usb: gadget: udc: core: don't starve DMA resources
Always unmap all SG entries as required by DMA API
Fixes: a698908d3b3b ("usb: gadget: add generic map/unmap request utilities")
Cc: # v3.4+
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/udc/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 934f83881c30..40c04bb25f2f 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -827,7 +827,7 @@ void usb_gadget_unmap_request_by_dev(struct device *dev,
return;
if (req->num_mapped_sgs) {
- dma_unmap_sg(dev, req->sg, req->num_mapped_sgs,
+ dma_unmap_sg(dev, req->sg, req->num_sgs,
is_in ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
req->num_mapped_sgs = 0;
--
2.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] usb: dwc3: gadget: don't consume non-started requests
If a request wasn't started, don't give it back. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 122e64df2f4d..594e82595634 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2064,6 +2064,10 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc, struct dwc3_ep *dep, break; } while (++i < req->request.num_mapped_sgs); + /* if actual is zero, it means req hasn't been transferred */ + if (req->request.actual == 0) + return 0; + /* * We assume here we will always receive the entire data block * which we should receive. Meaning, if we program RX to -- 2.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] usb: dwc3: debug: fix ep name on trace output
There was a typo when generating endpoint name which would be very confusing when debugging. Fix it. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/debug.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h index 22dfc3dd6a13..33ab2a203c1b 100644 --- a/drivers/usb/dwc3/debug.h +++ b/drivers/usb/dwc3/debug.h @@ -192,7 +192,7 @@ dwc3_ep_event_string(const struct dwc3_event_depevt *event) int ret; ret = sprintf(str, "ep%d%s: ", epnum >> 1, - (epnum & 1) ? "in" : "in"); + (epnum & 1) ? "in" : "out"); if (ret < 0) return "UNKNOWN"; -- 2.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/6] usb: dwc3: gadget: add remaining sg entries to ring
Hi,
John Youn writes:
> Hi Felipe,
>
> On 8/15/2016 4:02 AM, Felipe Balbi wrote:
>> Upon transfer completion after a full ring, let's
>> add more TRBs to our ring in order to complete our
>> request successfully.
>>
>> Signed-off-by: Felipe Balbi
>> ---
>> drivers/usb/dwc3/gadget.c | 36
>> 1 file changed, 24 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 90b3d7965136..6483991c8013 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -888,14 +888,13 @@ static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep)
>> static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
>> struct dwc3_request *req, unsigned int trbs_left)
>> {
>> -struct usb_request *request = &req->request;
>> -struct scatterlist *sg = request->sg;
>> +struct scatterlist *sg = req->sg;
>> struct scatterlist *s;
>> unsigned intlength;
>> dma_addr_t dma;
>> int i;
>>
>> -for_each_sg(sg, s, request->num_mapped_sgs, i) {
>> +for_each_sg(sg, s, req->num_pending_sgs, i) {
>> unsigned chain = true;
>>
>> length = sg_dma_len(s);
>> @@ -945,7 +944,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep)
>> return;
>>
>> list_for_each_entry_safe(req, n, &dep->pending_list, list) {
>> -if (req->request.num_mapped_sgs > 0)
>> +if (req->num_pending_sgs > 0)
>> dwc3_prepare_one_trb_sg(dep, req, trbs_left--);
>> else
>> dwc3_prepare_one_trb_linear(dep, req, trbs_left--);
>> @@ -1071,6 +1070,9 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
>> struct dwc3_request *req)
>> if (ret)
>> return ret;
>>
>> +req->sg = req->request.sg;
>> +req->num_pending_sgs= req->request.num_mapped_sgs;
>> +
>> list_add_tail(&req->list, &dep->pending_list);
>>
>> if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
>> @@ -1935,22 +1937,30 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
>> struct dwc3_ep *dep,
>> int ret;
>>
>> list_for_each_entry_safe(req, n, &dep->started_list, list) {
>> -
>> +unsigned length;
>> +unsigned actual;
>> int chain;
>>
>> -chain = req->request.num_mapped_sgs > 0;
>> +length = req->request.length;
>> +chain = req->num_pending_sgs > 0;
>> if (chain) {
>> -struct scatterlist *sg = req->request.sg;
>> +struct scatterlist *sg = req->sg;
>> struct scatterlist *s;
>> +unsigned int pending = req->num_pending_sgs;
>> unsigned int i;
>>
>> -for_each_sg(sg, s, req->request.num_mapped_sgs, i) {
>> +for_each_sg(sg, s, pending, i) {
>> trb = &dep->trb_pool[dep->trb_dequeue];
>> count += trb->size & DWC3_TRB_SIZE_MASK;
>> dwc3_ep_inc_deq(dep);
>>
>> +req->sg = sg_next(s);
>> +req->num_pending_sgs--;
>> +
>> ret = __dwc3_cleanup_done_trbs(dwc, dep, req,
>> trb,
>> event, status, chain);
>> +if (ret)
>> +break;
>> }
>> } else {
>> trb = &dep->trb_pool[dep->trb_dequeue];
>> @@ -1968,11 +1978,13 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
>> struct dwc3_ep *dep,
>> * should receive and we simply bounce the request back to the
>> * gadget driver for further processing.
>> */
>> -req->request.actual += req->request.length - count;
>> -dwc3_gadget_giveback(dep, req, status);
>> +actual = length - req->request.actual;
>> +req->request.actual = actual;
>>
>> -if (ret)
>> -break;
>> +if (ret && chain && (actual < length) && req->num_pending_sgs)
>> +return __dwc3_gadget_kick_transfer(dep, 0);
>> +
>> +dwc3_gadget_giveback(dep, req, status);
>> }
>>
>> /*
>>
>
> On your testing/next, I see considerable slow down and file
> corruption in mass storage.
>
> After bisecting, this patch seems to be the first one that shows
> problems. The device fails even enumeration here.
>
> I haven't looked in detail at the changes but, do you have any ideas?
>
> I have attached driver logs.
g_mass_storage doesn't use sglists, so I find this to be unlikely. I'll
test again but I didn't notice any problems on my side.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH V3] leds: trigger: Introduce an USB port trigger
On 24 August 2016 at 23:04, Greg KH wrote:
> On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote:
>> On 24 August 2016 at 11:22, Greg KH wrote:
>> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote:
>> >> +static ssize_t ports_show(struct device *dev, struct device_attribute
>> >> *attr,
>> >> + char *buf)
>> >> +{
>> >> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
>> >> + struct usbport_trig_data *usbport_data = led_cdev->trigger_data;
>> >> + struct usbport_trig_port *port;
>> >> + ssize_t ret = 0;
>> >> + int len;
>> >> +
>> >> + list_for_each_entry(port, &usbport_data->ports, list) {
>> >> + len = sprintf(buf + ret, "%s\n", port->name);
>> >> + if (len >= 0)
>> >> + ret += len;
>> >> + }
>> >> +
>> >> + return ret;
>> >> +}
>> >
>> > sysfs is "one value per file", here you are listing a bunch of things in
>> > one sysfs file. Please don't do that.
>>
>> OK. What do you think about creating "ports" subdirectory and creating
>> file-per-port in it? Then I'd need to bring back something like
>> "new_port" and "remove_port". Does it sound OK?
>
> Maybe, I don't know. Why is "USB" somehow unique here? Why isn't this
> the same for PCI slots/ports? pccard? sdcard? thunderbolt?
Good question. I would like to extend this USB port trigger in the
future by reacting to USB activity. This involves playing with URBs
and I believe that at that point it'd be getting too much USB specific
to /rule them all/.
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/6] usb: dwc3: gadget: add remaining sg entries to ring
Hi, Felipe Balbi writes: >> On your testing/next, I see considerable slow down and file >> corruption in mass storage. >> >> After bisecting, this patch seems to be the first one that shows >> problems. The device fails even enumeration here. >> >> I haven't looked in detail at the changes but, do you have any ideas? >> >> I have attached driver logs. > > g_mass_storage doesn't use sglists, so I find this to be unlikely. I'll > test again but I didn't notice any problems on my side. Few things: Host sent you a few Resets which I don't know why they're there: irq/16-dwc3-2849 [002] d..245.257835: dwc3_event: event (0101): Reset [U0] [...] irq/16-dwc3-2849 [002] d..245.352847: dwc3_event: event (0101): Reset [U0] [...] irq/16-dwc3-2849 [002] d..245.257835: dwc3_event: event (0101): Reset [U0] [...] 4 requests per endpoint, why so few? To test throughput, I've been using 96 requests per endpoint :-p file-storage-2848 [003] ...145.319500: dwc3_alloc_request: ep1in: req 8ba68ead9ce8 length 0/0 zsI ==> 0 file-storage-2848 [003] ...145.319505: dwc3_alloc_request: ep1out: req 8ba68eadad68 length 0/0 zsI ==> 0 file-storage-2848 [003] ...145.319510: dwc3_alloc_request: ep1in: req 8ba68ead9ef8 length 0/0 zsI ==> 0 file-storage-2848 [003] ...145.319514: dwc3_alloc_request: ep1out: req 8ba68ead98c8 length 0/0 zsI ==> 0 file-storage-2848 [003] ...145.319519: dwc3_alloc_request: ep1in: req 8ba68eadb9c8 length 0/0 zsI ==> 0 file-storage-2848 [003] ...145.319524: dwc3_alloc_request: ep1out: req 8ba68eadb5a8 length 0/0 zsI ==> 0 file-storage-2848 [003] ...145.319528: dwc3_alloc_request: ep1in: req 8ba68eadb188 length 0/0 zsI ==> 0 file-storage-2848 [003] ...145.319533: dwc3_alloc_request: ep1out: req 8ba68ead9ad8 length 0/0 zsI ==> 0 In fact, there are no bulk ep transfers on your log. Why's that? What is the host doing? -- balbi signature.asc Description: PGP signature
[PATCH V4] leds: trigger: Introduce an USB port trigger
From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires specifying USB port in a Linux format (e.g. echo 1-1 > new_port). During work on this trigger there was a plan to add DT bindings for it, but there wasn't an agreement on the format yet. This can be worked on later, a sysfs interface is needed anyway for platforms not using DT. Another planned feature is support for LED reacting to the USB activity. This can be implemented with another sysfs file for setting mode. The default mode wouldn't change so there won't be ABI breakage and such feature can be safely implemented later. Signed-off-by: Rafał Miłecki --- V2: Trying to add DT support, idea postponed as it will take more time to discuss the bindings. V3: Fix typos in commit and Documentation (thanks Jacek!) Use "ports" sysfs file for adding and removing USB ports (thx Jacek) Check if there is USB device connected after adding new USB port Fix memory leak or two V3.5: Fix e-mail address (thanks Matthias) Simplify conditions in usbport_trig_notify (thx Matthias) Make "ports" a subdirectory with file per port, to match one value per file sysfs rule (thanks Greg) As "ports" couldn't be used for adding and removing ports anymore, there are now "new_port" and "remove_port". Having them makes this API also common with e.g. pci and usb buses. V4: Add Documentation/ABI/testing/sysfs-class-led-trigger-usbport and reference it in Documentation/leds/ledtrig-usbport.txt to avoid doc duplication. --- .../ABI/testing/sysfs-class-led-trigger-usbport| 25 ++ Documentation/leds/ledtrig-usbport.txt | 46 +++ drivers/leds/trigger/Kconfig | 8 + drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-usbport.c | 309 + 5 files changed, 389 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-usbport create mode 100644 Documentation/leds/ledtrig-usbport.txt create mode 100644 drivers/leds/trigger/ledtrig-usbport.c diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-usbport b/Documentation/ABI/testing/sysfs-class-led-trigger-usbport new file mode 100644 index 000..653bde1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-usbport @@ -0,0 +1,25 @@ +What: /sys/class/leds//new_port +Date: August 2016 +KernelVersion: 4.9 +Contact: linux-l...@vger.kernel.org +Description: + Adds USB port (specified by a name using Linux format, e.g. 1-1) + to the list of observable ones. This will have immediate effect + if there is device already connected. This will also make + trigger checking for a match on every USB (dis)connection event. + +What: /sys/class/leds//remove_port +Date: August 2016 +KernelVersion: 4.9 +Contact: linux-l...@vger.kernel.org +Description: + This allows removing USB port from the list of observable ones. + +What: /sys/class/leds//ports/ +Date: August 2016 +KernelVersion: 4.9 +Contact: linux-l...@vger.kernel.org +Description: + Every port entry is a name (in Linux format) of USB port that is + being observed by the usbport trigger. It's useful for checking + the current state of trigger setup. diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt new file mode 100644 index 000..8e36e2d --- /dev/null +++ b/Documentation/leds/ledtrig-usbport.txt @@ -0,0 +1,46 @@ +USB port LED trigger + + +This LED trigger can be used for signalling to the user a presence of USB device +in a given port. It simply turns on LED when device appears and turns it off +when it disappears. + +It requires specifying a list of USB ports that should be observed. Used format +matches Linux kernel format and consists of a root hub number and a hub port +separated by a dash (e.g. 3-1). + +It is also possible to handle devices with internal hubs (that are always +connected to the root hub). User can simply specify internal hub ports then +(e.g. 1-1.1, 1-1.2, etc.). + +Please note that this trigger allows assigning multiple USB ports to a single +LED. This can be useful in two cases: + +1) Device with single USB LED and few physical ports + +In such a case LED will be turned on as long as there is at least one connected +USB device. + +2) Device with a physical port handled by few controllers + +Some devices have e.g. one controller per PHY standard. E.g. USB 3.0 physical +port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
zOn 08/24/2016 07:52 PM, Rafał Miłecki wrote: From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires specifying USB port in a Linux format (e.g. echo 1-1 > new_port). During work on this trigger there was a plan to add DT bindings for it, but there wasn't an agreement on the format yet. This can be worked on later, a sysfs interface is needed anyway for platforms not using DT. Signed-off-by: Rafał Miłecki --- V2: Trying to add DT support, idea postponed as it will take more time to discuss the bindings. V3: Fix typos in commit and Documentation (thanks Jacek!) Use "ports" sysfs file for adding and removing USB ports (thx Jacek) Check if there is USB device connected after adding new USB port Fix memory leak or two V3.5: Fix e-mail address (thanks Matthias) Simplify conditions in usbport_trig_notify (thx Matthias) Make "ports" a subdirectory with file per port, to match one value per file sysfs rule (thanks Greg) As "ports" couldn't be used for adding and removing ports anymore, there are now "new_port" and "remove_port". Having them makes this API also common with e.g. pci and usb buses. Now writing new_port with "1-1" produces a file named "1-1" in the ports directory with 000 permissions. I think that what Greg had on mind by referring to "one value per file" rule was a set of files representing ports, like "1-1 1-2 2-1", and each file should be readable/writeable. For instance "echo 1 > 1-1" would enable the trigger for the port 1-1 and "echo 0 > 1-1" would disable it. The problem is that we don't know the number of required ports at compilation time and the sysfs attributes would have to be dynamically created on driver instantiation. What is more, as the USB ports can dynamically appear/disappear in the system, the files would have to be created/removed accordingly during LED class device lifetime, which is not the best design for the sysfs interface I think. Therefore, maybe it would be good to follow the "triggers" sysfs attribute pattern, where it lists the available LED triggers? The question is whether there is some mechanism available for notifying addition/removal of a USB port? Also a description of the device connected to the port would be a nice feature, however I am not certain about the feasibility thereof. The last big missing thing is Documentation update (this is why I'm sending RFC). Greg pointed out we should have some entries in Documentation/ABI, but it seems none of triggers have it. Any idea why is that? Do we need to change it? Or is it required for new code only? If so, should I care about Documentation/leds/ledtrig-usbport.txt at all in this patch? For now I didn't update Documentation/leds/ledtrig-usbport.txt with the new new_port and remove_port API, until I get a clue how to proceed. --- Documentation/leds/ledtrig-usbport.txt | 49 ++ drivers/leds/trigger/Kconfig | 8 + drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-usbport.c | 309 + 4 files changed, 367 insertions(+) create mode 100644 Documentation/leds/ledtrig-usbport.txt create mode 100644 drivers/leds/trigger/ledtrig-usbport.c diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt new file mode 100644 index 000..fa42227 --- /dev/null +++ b/Documentation/leds/ledtrig-usbport.txt @@ -0,0 +1,49 @@ +USB port LED trigger + + +This LED trigger can be used for signalling to the user a presence of USB device +in a given port. It simply turns on LED when device appears and turns it off +when it disappears. + +It requires specifying a list of USB ports that should be observed. Used format +matches Linux kernel format and consists of a root hub number and a hub port +separated by a dash (e.g. 3-1). + +It is also possible to handle devices with internal hubs (that are always +connected to the root hub). User can simply specify internal hub ports then +(e.g. 1-1.1, 1-1.2, etc.). + +Please note that this trigger allows assigning multiple USB ports to a single +LED. This can be useful in two cases: + +1) Device with single USB LED and few physical ports + +In such a case LED will be turned on as long as there is at least one connected +USB device. + +2) Device with a physical port handled by few controllers + +Some devices have e.g. one controller per PHY standard. E.g. USB 3.0 physical +port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there is +only one LED user will most likely want to assign ports from all 3 hubs. + + +This trigger can be activated from user space on led class devices as shown +below: + + echo usbport > trigger
Re: [PATCH v2 4/6] usb: dwc3: gadget: add remaining sg entries to ring
Hi, Felipe Balbi writes: > Felipe Balbi writes: >>> On your testing/next, I see considerable slow down and file >>> corruption in mass storage. >>> >>> After bisecting, this patch seems to be the first one that shows >>> problems. The device fails even enumeration here. >>> >>> I haven't looked in detail at the changes but, do you have any ideas? >>> >>> I have attached driver logs. >> >> g_mass_storage doesn't use sglists, so I find this to be unlikely. I'll >> test again but I didn't notice any problems on my side. > > Few things: > > Host sent you a few Resets which I don't know why they're there: > > irq/16-dwc3-2849 [002] d..245.257835: dwc3_event: event (0101): > Reset [U0] > > [...] > > irq/16-dwc3-2849 [002] d..245.352847: dwc3_event: event (0101): > Reset [U0] > > [...] > > irq/16-dwc3-2849 [002] d..245.257835: dwc3_event: event (0101): > Reset [U0] > > [...] > > 4 requests per endpoint, why so few? To test throughput, I've been using > 96 requests per endpoint :-p > > file-storage-2848 [003] ...145.319500: dwc3_alloc_request: ep1in: > req 8ba68ead9ce8 length 0/0 zsI ==> 0 > file-storage-2848 [003] ...145.319505: dwc3_alloc_request: ep1out: > req 8ba68eadad68 length 0/0 zsI ==> 0 > file-storage-2848 [003] ...145.319510: dwc3_alloc_request: ep1in: > req 8ba68ead9ef8 length 0/0 zsI ==> 0 > file-storage-2848 [003] ...145.319514: dwc3_alloc_request: ep1out: > req 8ba68ead98c8 length 0/0 zsI ==> 0 > file-storage-2848 [003] ...145.319519: dwc3_alloc_request: ep1in: > req 8ba68eadb9c8 length 0/0 zsI ==> 0 > file-storage-2848 [003] ...145.319524: dwc3_alloc_request: ep1out: > req 8ba68eadb5a8 length 0/0 zsI ==> 0 > file-storage-2848 [003] ...145.319528: dwc3_alloc_request: ep1in: > req 8ba68eadb188 length 0/0 zsI ==> 0 > file-storage-2848 [003] ...145.319533: dwc3_alloc_request: ep1out: > req 8ba68ead9ad8 length 0/0 zsI ==> 0 > > In fact, there are no bulk ep transfers on your log. Why's that? What is > the host doing? I can reproduce this here and I'm now looking at it. -- balbi signature.asc Description: PGP signature
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
On 25/08/16 10:03, Jacek Anaszewski wrote: zOn 08/24/2016 07:52 PM, Rafał Miłecki wrote: From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires specifying USB port in a Linux format (e.g. echo 1-1 > new_port). During work on this trigger there was a plan to add DT bindings for it, but there wasn't an agreement on the format yet. This can be worked on later, a sysfs interface is needed anyway for platforms not using DT. Signed-off-by: Rafał Miłecki --- V2: Trying to add DT support, idea postponed as it will take more time to discuss the bindings. V3: Fix typos in commit and Documentation (thanks Jacek!) Use "ports" sysfs file for adding and removing USB ports (thx Jacek) Check if there is USB device connected after adding new USB port Fix memory leak or two V3.5: Fix e-mail address (thanks Matthias) Simplify conditions in usbport_trig_notify (thx Matthias) Make "ports" a subdirectory with file per port, to match one value per file sysfs rule (thanks Greg) As "ports" couldn't be used for adding and removing ports anymore, there are now "new_port" and "remove_port". Having them makes this API also common with e.g. pci and usb buses. Now writing new_port with "1-1" produces a file named "1-1" in the ports directory with 000 permissions. I think that what Greg had on mind by referring to "one value per file" rule was a set of files representing ports, like "1-1 1-2 2-1", and each file should be readable/writeable. For instance "echo 1 > 1-1" would enable the trigger for the port 1-1 and "echo 0 > 1-1" would disable it. The problem is that we don't know the number of required ports at compilation time and the sysfs attributes would have to be dynamically created on driver instantiation. What is more, as the USB ports can dynamically appear/disappear in the system, the files would have to be created/removed accordingly during LED class device lifetime, which is not the best design for the sysfs interface I think. Therefore, maybe it would be good to follow the "triggers" sysfs attribute pattern, where it lists the available LED triggers? The question is whether there is some mechanism available for notifying addition/removal of a USB port? I think this should be easily doable through the notifier catching USB_BUS_[ADD,REMOVE]. Regards, Matthias Also a description of the device connected to the port would be a nice feature, however I am not certain about the feasibility thereof. The last big missing thing is Documentation update (this is why I'm sending RFC). Greg pointed out we should have some entries in Documentation/ABI, but it seems none of triggers have it. Any idea why is that? Do we need to change it? Or is it required for new code only? If so, should I care about Documentation/leds/ledtrig-usbport.txt at all in this patch? For now I didn't update Documentation/leds/ledtrig-usbport.txt with the new new_port and remove_port API, until I get a clue how to proceed. --- Documentation/leds/ledtrig-usbport.txt | 49 ++ drivers/leds/trigger/Kconfig | 8 + drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-usbport.c | 309 + 4 files changed, 367 insertions(+) create mode 100644 Documentation/leds/ledtrig-usbport.txt create mode 100644 drivers/leds/trigger/ledtrig-usbport.c diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt new file mode 100644 index 000..fa42227 --- /dev/null +++ b/Documentation/leds/ledtrig-usbport.txt @@ -0,0 +1,49 @@ +USB port LED trigger + + +This LED trigger can be used for signalling to the user a presence of USB device +in a given port. It simply turns on LED when device appears and turns it off +when it disappears. + +It requires specifying a list of USB ports that should be observed. Used format +matches Linux kernel format and consists of a root hub number and a hub port +separated by a dash (e.g. 3-1). + +It is also possible to handle devices with internal hubs (that are always +connected to the root hub). User can simply specify internal hub ports then +(e.g. 1-1.1, 1-1.2, etc.). + +Please note that this trigger allows assigning multiple USB ports to a single +LED. This can be useful in two cases: + +1) Device with single USB LED and few physical ports + +In such a case LED will be turned on as long as there is at least one connected +USB device. + +2) Device with a physical port handled by few controllers + +Some devices have e.g. one controller per PHY standard. E.g. USB 3.0 physical +port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there is +only one LED user will most lik
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
On 25 August 2016 at 10:03, Jacek Anaszewski wrote: > On 08/24/2016 07:52 PM, Rafał Miłecki wrote: >> >> From: Rafał Miłecki >> >> This commit adds a new trigger responsible for turning on LED when USB >> device gets connected to the specified USB port. This can can useful for >> various home routers that have USB port(s) and a proper LED telling user >> a device is connected. >> >> The trigger gets its documentation file but basically it just requires >> specifying USB port in a Linux format (e.g. echo 1-1 > new_port). >> >> During work on this trigger there was a plan to add DT bindings for it, >> but there wasn't an agreement on the format yet. This can be worked on >> later, a sysfs interface is needed anyway for platforms not using DT. >> >> Signed-off-by: Rafał Miłecki >> --- >> V2: Trying to add DT support, idea postponed as it will take more time >> to discuss the bindings. >> V3: Fix typos in commit and Documentation (thanks Jacek!) >> Use "ports" sysfs file for adding and removing USB ports (thx Jacek) >> Check if there is USB device connected after adding new USB port >> Fix memory leak or two >> V3.5: Fix e-mail address (thanks Matthias) >> Simplify conditions in usbport_trig_notify (thx Matthias) >> Make "ports" a subdirectory with file per port, to match one value >> per file sysfs rule (thanks Greg) >> As "ports" couldn't be used for adding and removing ports anymore, >> there are now "new_port" and "remove_port". Having them makes this >> API also common with e.g. pci and usb buses. > > > Now writing new_port with "1-1" produces a file named "1-1" in the > ports directory with 000 permissions. I think that what Greg had > on mind by referring to "one value per file" rule was a set of > files representing ports, like "1-1 1-2 2-1", and each file should be > readable/writeable. > > For instance "echo 1 > 1-1" would enable the trigger for the port 1-1 > and "echo 0 > 1-1" would disable it. The problem is that we don't know > the number of required ports at compilation time and the sysfs > attributes would have to be dynamically created on driver instantiation. > What is more, as the USB ports can dynamically appear/disappear in the > system, the files would have to be created/removed accordingly during > LED class device lifetime, which is not the best design for the sysfs > interface I think. > > Therefore, maybe it would be good to follow the "triggers" sysfs > attribute pattern, where it lists the available LED triggers? > > The question is whether there is some mechanism available for > notifying addition/removal of a USB port? Every port is part of some hub and every hub (even root one) is a USB device. So I could just get struct usb_device and check its "maxchild" property. If e.g. I get USB device "1-1" with maxchild 4, I know there are: 1-1.1 1-1.2 1-1.3 1-1.4 So the sysfs structure you suggested would be possible, I just don't know if it's preferred one or not. Confirmation: yes, right now I create simple files with chmod 000 for every port added to the usbport observable list. > Also a description of the device connected to the port would be a nice > feature, however I am not certain about the feasibility thereof. What kind of description do you mean? Where should it be used / where should it appear? -- Rafał -- 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: [RESEND PATCH, v5 4/5] usb: Add MediaTek USB3 DRD Driver
On Thu, 2016-08-25 at 11:05 +0800, Chunfeng Yun wrote:
> This patch adds support for the MediaTek USB3 controller
> integrated into MT8173. It can be configured as Dual-Role
> Device (DRD), Peripheral Only and Host Only (xHCI) modes.
>
> +/**
> + * General Purpose Descriptor (GPD):
> + * The format of TX GPD is a little different from RX one.
> + * And the size of GPD is 16 bytes.
> + *
> + * @flag:
> + * bit0: Hardware Own (HWO)
> + * bit1: Buffer Descriptor Present (BDP), always 0, BD is not supported
> + * bit2: Bypass (BPS), 1: HW skips this GPD if HWO = 1
> + * bit7: Interrupt On Completion (IOC)
> + * @chksum: This is used to validate the contents of this GPD;
> + * If TXQ_CS_EN / RXQ_CS_EN bit is set, an interrupt is issued
> + * when checksum validation fails;
> + * Checksum value is calculated over the 16 bytes of the GPD by default;
> + * @data_buf_len (RX ONLY): This value indicates the length of
> + * the assigned data buffer
> + * @next_gpd: Physical address of the next GPD
> + * @buffer: Physical address of the data buffer
> + * @buf_len:
> + * (TX): This value indicates the length of the assigned data buffer
> + * (RX): The total length of data received
> + * @ext_len: reserved
> + * @ext_flag:
> + * bit5 (TX ONLY): Zero Length Packet (ZLP),
> + */
> +struct qmu_gpd {
> + u8 flag;
> + u8 chksum;
> + u16 data_buf_len;
> + u32 next_gpd;
> + u32 buffer;
> + u16 buf_len;
> + u8 ext_len;
> + u8 ext_flag;
> +} __packed;
It looks like this is shared with hardware in memory.
But you leave the endianness of the bigger fields undeclared.
> +/**
> +* dma: physical base address of GPD segment
> +* start: virtual base address of GPD segment
> +* end: the last GPD element
> +* enqueue: the first empty GPD to use
> +* dequeue: the first completed GPD serviced by ISR
> +* NOTE: the size of GPD ring should be >= 2
> +*/
> +struct mtu3_gpd_ring {
> + dma_addr_t dma;
> + struct qmu_gpd *start;
> + struct qmu_gpd *end;
> + struct qmu_gpd *enqueue;
> + struct qmu_gpd *dequeue;
> +};
> +
> +/**
> +* @vbus: vbus 5V used by host mode
> +* @edev: external connector used to detect vbus and iddig changes
> +* @vbus_nb: notifier for vbus detection
> +* @vbus_nb: notifier for iddig(idpin) detection
> +* @extcon_reg_dwork: delay work for extcon notifier register, waiting for
> +*xHCI driver initialization, it's necessary for system bootup
> +*as device.
> +* @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
> +* @id_*: used to maually switch between host and device modes by idpin
> +* @manual_drd_enabled: it's true when supports dual-role device by debugfs
> +*to switch host/device modes depending on user input.
Please use a common interface for this. The Intel people are introducing
one.
> +#endif
> diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
> new file mode 100644
> index 000..fdc11b6
> --- /dev/null
> +++ b/drivers/usb/mtu3/mtu3_core.c
> @@ -0,0 +1,874 @@
> +/*
> + * mtu3_core.c - hardware access layer and gadget init/exit of
> + * MediaTek usb3 Dual-Role Controller Driver
> + *
> + * Copyright (C) 2016 MediaTek Inc.
> + *
> + * Author: Chunfeng Yun
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtu3.h"
> +
> +static int ep_fifo_alloc(struct mtu3_ep *mep, u32 seg_size)
> +{
> + struct mtu3_fifo_info *fifo = mep->fifo;
> + u32 num_bits = DIV_ROUND_UP(seg_size, MTU3_EP_FIFO_UNIT);
> + u32 start_bit;
> +
> + /* ensure that @mep->fifo_seg_size is power of two */
> + num_bits = roundup_pow_of_two(num_bits);
> + if (num_bits > fifo->limit)
> + return -EINVAL;
> +
> + mep->fifo_seg_size = num_bits * MTU3_EP_FIFO_UNIT;
> + num_bits = num_bits * (mep->slot + 1);
> + start_bit = bitmap_find_next_zero_area(fifo->bitmap,
> + fifo->limit, 0, num_bits, 0);
> + if (start_bit >= fifo->limit)
> + return -EOVERFLOW;
> +
> + bitmap_set(fifo->bitmap, start_bit, num_bits);
> + mep->fifo_size = num_bits * MTU3_EP_FIFO_UNIT;
> + mep->fifo_addr = fifo->base + MTU3_EP_FIFO_UNIT * start_bit;
> +
> + dev_dbg(mep->mtu->dev, "%s fifo:%#x/%#x, start_bit: %d\n",
> + __func__, mep->fifo_seg_size, mep->fifo_size, start_bit);
If you use the "f" option to dynamic debugging it will give you the
function name anyway. So why inclu
Re: [PATCH] usb: renesas_usbhs: add a compatible string for r8a7796
On Wed, Aug 24, 2016 at 9:39 AM, Yoshihiro Shimoda
wrote:
> This patch adds support for r8a7796 (R-Car M3-W).
>
> Signed-off-by: Yoshihiro Shimoda
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 RFC V3.5] leds: trigger: Introduce an USB port trigger
On 25 August 2016 at 10:03, Jacek Anaszewski wrote: > On 08/24/2016 07:52 PM, Rafał Miłecki wrote: >> >> From: Rafał Miłecki >> >> This commit adds a new trigger responsible for turning on LED when USB >> device gets connected to the specified USB port. This can can useful for >> various home routers that have USB port(s) and a proper LED telling user >> a device is connected. >> >> The trigger gets its documentation file but basically it just requires >> specifying USB port in a Linux format (e.g. echo 1-1 > new_port). >> >> During work on this trigger there was a plan to add DT bindings for it, >> but there wasn't an agreement on the format yet. This can be worked on >> later, a sysfs interface is needed anyway for platforms not using DT. >> >> Signed-off-by: Rafał Miłecki >> --- >> V2: Trying to add DT support, idea postponed as it will take more time >> to discuss the bindings. >> V3: Fix typos in commit and Documentation (thanks Jacek!) >> Use "ports" sysfs file for adding and removing USB ports (thx Jacek) >> Check if there is USB device connected after adding new USB port >> Fix memory leak or two >> V3.5: Fix e-mail address (thanks Matthias) >> Simplify conditions in usbport_trig_notify (thx Matthias) >> Make "ports" a subdirectory with file per port, to match one value >> per file sysfs rule (thanks Greg) >> As "ports" couldn't be used for adding and removing ports anymore, >> there are now "new_port" and "remove_port". Having them makes this >> API also common with e.g. pci and usb buses. > > > Now writing new_port with "1-1" produces a file named "1-1" in the > ports directory with 000 permissions. I think that what Greg had > on mind by referring to "one value per file" rule was a set of > files representing ports, like "1-1 1-2 2-1", and each file should be > readable/writeable. On the other hand, when I described my idea with "new_port" and "remove_port", Greg replied with "Maybe", so I'm not sure if he really got a design you described in his mind. Greg: could you comment on this sysfs interface, please? :) -- Rafał -- 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 RFC V3.5] leds: trigger: Introduce an USB port trigger
On 08/25/2016 10:29 AM, Rafał Miłecki wrote: On 25 August 2016 at 10:03, Jacek Anaszewski wrote: On 08/24/2016 07:52 PM, Rafał Miłecki wrote: From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires specifying USB port in a Linux format (e.g. echo 1-1 > new_port). During work on this trigger there was a plan to add DT bindings for it, but there wasn't an agreement on the format yet. This can be worked on later, a sysfs interface is needed anyway for platforms not using DT. Signed-off-by: Rafał Miłecki --- V2: Trying to add DT support, idea postponed as it will take more time to discuss the bindings. V3: Fix typos in commit and Documentation (thanks Jacek!) Use "ports" sysfs file for adding and removing USB ports (thx Jacek) Check if there is USB device connected after adding new USB port Fix memory leak or two V3.5: Fix e-mail address (thanks Matthias) Simplify conditions in usbport_trig_notify (thx Matthias) Make "ports" a subdirectory with file per port, to match one value per file sysfs rule (thanks Greg) As "ports" couldn't be used for adding and removing ports anymore, there are now "new_port" and "remove_port". Having them makes this API also common with e.g. pci and usb buses. Now writing new_port with "1-1" produces a file named "1-1" in the ports directory with 000 permissions. I think that what Greg had on mind by referring to "one value per file" rule was a set of files representing ports, like "1-1 1-2 2-1", and each file should be readable/writeable. For instance "echo 1 > 1-1" would enable the trigger for the port 1-1 and "echo 0 > 1-1" would disable it. The problem is that we don't know the number of required ports at compilation time and the sysfs attributes would have to be dynamically created on driver instantiation. What is more, as the USB ports can dynamically appear/disappear in the system, the files would have to be created/removed accordingly during LED class device lifetime, which is not the best design for the sysfs interface I think. Therefore, maybe it would be good to follow the "triggers" sysfs attribute pattern, where it lists the available LED triggers? The question is whether there is some mechanism available for notifying addition/removal of a USB port? Every port is part of some hub and every hub (even root one) is a USB device. So I could just get struct usb_device and check its "maxchild" property. If e.g. I get USB device "1-1" with maxchild 4, I know there are: 1-1.1 1-1.2 1-1.3 1-1.4 So the sysfs structure you suggested would be possible, I just don't know if it's preferred one or not. It would require an ack from Greg. I'd see it as follows: #cat available_ports #1-1 1-2 2-1 #echo "1-1" > new_port #cat observed_ports #1-1 #echo "2-1" > new_port #cat observed_ports #1-1 2-1 We've already had few discussions about the sysfs designs trying to break the one-value-per-file rule for LED class device, and there was always strong resistance against. Cc Pavel. Confirmation: yes, right now I create simple files with chmod 000 for every port added to the usbport observable list. Also a description of the device connected to the port would be a nice feature, however I am not certain about the feasibility thereof. What kind of description do you mean? Where should it be used / where should it appear? Product name/symbol. Actually it should be USB subsystem responsibility to provide the means for querying the product name by port id, if it is possible at all. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/6] usb: dwc3: gadget: add remaining sg entries to ring
Hi, Felipe Balbi writes: > Felipe Balbi writes: >> Felipe Balbi writes: On your testing/next, I see considerable slow down and file corruption in mass storage. After bisecting, this patch seems to be the first one that shows problems. The device fails even enumeration here. I haven't looked in detail at the changes but, do you have any ideas? I have attached driver logs. >>> >>> g_mass_storage doesn't use sglists, so I find this to be unlikely. I'll >>> test again but I didn't notice any problems on my side. >> >> Few things: >> >> Host sent you a few Resets which I don't know why they're there: >> >> irq/16-dwc3-2849 [002] d..245.257835: dwc3_event: event >> (0101): Reset [U0] >> >> [...] >> >> irq/16-dwc3-2849 [002] d..245.352847: dwc3_event: event >> (0101): Reset [U0] >> >> [...] >> >> irq/16-dwc3-2849 [002] d..245.257835: dwc3_event: event >> (0101): Reset [U0] >> >> [...] >> >> 4 requests per endpoint, why so few? To test throughput, I've been using >> 96 requests per endpoint :-p >> >> file-storage-2848 [003] ...145.319500: dwc3_alloc_request: ep1in: >> req 8ba68ead9ce8 length 0/0 zsI ==> 0 >> file-storage-2848 [003] ...145.319505: dwc3_alloc_request: ep1out: >> req 8ba68eadad68 length 0/0 zsI ==> 0 >> file-storage-2848 [003] ...145.319510: dwc3_alloc_request: ep1in: >> req 8ba68ead9ef8 length 0/0 zsI ==> 0 >> file-storage-2848 [003] ...145.319514: dwc3_alloc_request: ep1out: >> req 8ba68ead98c8 length 0/0 zsI ==> 0 >> file-storage-2848 [003] ...145.319519: dwc3_alloc_request: ep1in: >> req 8ba68eadb9c8 length 0/0 zsI ==> 0 >> file-storage-2848 [003] ...145.319524: dwc3_alloc_request: ep1out: >> req 8ba68eadb5a8 length 0/0 zsI ==> 0 >> file-storage-2848 [003] ...145.319528: dwc3_alloc_request: ep1in: >> req 8ba68eadb188 length 0/0 zsI ==> 0 >> file-storage-2848 [003] ...145.319533: dwc3_alloc_request: ep1out: >> req 8ba68ead9ad8 length 0/0 zsI ==> 0 >> >> In fact, there are no bulk ep transfers on your log. Why's that? What is >> the host doing? > > I can reproduce this here and I'm now looking at it. Here's an incremental patch to update $subject. It's working fine on SKL. diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 27cf4d74db06..37a86522fa88 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1980,6 +1980,9 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc, struct dwc3_ep *dep, return __dwc3_gadget_kick_transfer(dep, 0); dwc3_gadget_giveback(dep, req, status); + + if (ret) + break; } /* I have force-pushed testing/next with this update too. -- balbi signature.asc Description: PGP signature
[PATCH v3] usb: dwc3: gadget: add remaining sg entries to ring
Upon transfer completion after a full ring, let's
add more TRBs to our ring in order to complete our
request successfully.
Signed-off-by: Felipe Balbi
---
Changes since v1:
- none
Changes since v2:
- fix regression found by John Youn
drivers/usb/dwc3/gadget.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 90b3d7965136..c18bf1caad54 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -888,14 +888,13 @@ static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep)
static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
struct dwc3_request *req, unsigned int trbs_left)
{
- struct usb_request *request = &req->request;
- struct scatterlist *sg = request->sg;
+ struct scatterlist *sg = req->sg;
struct scatterlist *s;
unsigned intlength;
dma_addr_t dma;
int i;
- for_each_sg(sg, s, request->num_mapped_sgs, i) {
+ for_each_sg(sg, s, req->num_pending_sgs, i) {
unsigned chain = true;
length = sg_dma_len(s);
@@ -945,7 +944,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep)
return;
list_for_each_entry_safe(req, n, &dep->pending_list, list) {
- if (req->request.num_mapped_sgs > 0)
+ if (req->num_pending_sgs > 0)
dwc3_prepare_one_trb_sg(dep, req, trbs_left--);
else
dwc3_prepare_one_trb_linear(dep, req, trbs_left--);
@@ -1071,6 +1070,9 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
if (ret)
return ret;
+ req->sg = req->request.sg;
+ req->num_pending_sgs= req->request.num_mapped_sgs;
+
list_add_tail(&req->list, &dep->pending_list);
if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
@@ -1935,22 +1937,30 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
int ret;
list_for_each_entry_safe(req, n, &dep->started_list, list) {
-
+ unsigned length;
+ unsigned actual;
int chain;
- chain = req->request.num_mapped_sgs > 0;
+ length = req->request.length;
+ chain = req->num_pending_sgs > 0;
if (chain) {
- struct scatterlist *sg = req->request.sg;
+ struct scatterlist *sg = req->sg;
struct scatterlist *s;
+ unsigned int pending = req->num_pending_sgs;
unsigned int i;
- for_each_sg(sg, s, req->request.num_mapped_sgs, i) {
+ for_each_sg(sg, s, pending, i) {
trb = &dep->trb_pool[dep->trb_dequeue];
count += trb->size & DWC3_TRB_SIZE_MASK;
dwc3_ep_inc_deq(dep);
+ req->sg = sg_next(s);
+ req->num_pending_sgs--;
+
ret = __dwc3_cleanup_done_trbs(dwc, dep, req,
trb,
event, status, chain);
+ if (ret)
+ break;
}
} else {
trb = &dep->trb_pool[dep->trb_dequeue];
@@ -1968,7 +1978,12 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
* should receive and we simply bounce the request back to the
* gadget driver for further processing.
*/
- req->request.actual += req->request.length - count;
+ actual = length - req->request.actual;
+ req->request.actual = actual;
+
+ if (ret && chain && (actual < length) && req->num_pending_sgs)
+ return __dwc3_gadget_kick_transfer(dep, 0);
+
dwc3_gadget_giveback(dep, req, status);
if (ret)
--
2.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usbnet: ax88179_178a: Add support for writing the EEPROM
On Wed, 2016-08-24 at 16:40 +0200, Alban Bedel wrote: > On Wed, 24 Aug 2016 16:30:39 +0200 > Oliver Neukum wrote: > > > On Wed, 2016-08-24 at 15:52 +0200, Alban Bedel wrote: > > > + if (block != data) > > > + kfree(block); > > > > And if block == dta, what frees the memory? > > In this case this function didn't allocate any memory, so there is > nothing to free. Hi, I see. kfree() has a check for NULL, so you could drop the test, but it doesn't matter much either way. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: chipidea: hdc: kernel panic during shutdown
On Thu, Aug 25, 2016 at 08:27:03AM +0200, Stefan Wahren wrote:
> Am 25.08.2016 um 08:44 schrieb Peter Chen:
> > On Thu, Aug 25, 2016 at 07:06:12AM +0200, Stefan Wahren wrote:
> >> Hi Alan,
> >>
> >> i tried the following patch:
> >> --- a/drivers/usb/chipidea/host.c
> >> +++ b/drivers/usb/chipidea/host.c
> >> @@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
> >>
> >> if (hcd) {
> >> usb_remove_hcd(hcd);
> >> + ci_role_stop(ci);
> >> + synchronize_irq(ci->irq);
> > Would you please just add below line to see if this problem can be
> > fixed?
> > + ci->role = CI_ROLE_END;
> >
> > When ci->role is CI_ROLE_END, neither host nor device interrupt handler
> > will run.
>
> I would add this before synchronize_irq() as Alan suggested.
>
> >
> > What is your controller role? (dr_mode = host, peripheral or otg)?
>
> I'm using the unmodified arch/arm/boot/dts/imx23-olinuxino.dts so:
>
> dr_mode = host
It is so strange that there are interrupts after usb_remove_hcd is
called since the controller has already at reset status.
>
> > Besides, you would please add below line at core.c to show what
> > interrupt occurs at that time:
> >
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index b5c155b..e6b8a7e 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -596,6 +596,12 @@ static irqreturn_t ci_irq(int irq, void *data)
> > /* Handle device/host interrupt */
> > if (ci->role != CI_ROLE_END)
> > ret = ci_role(ci)->irq(ci);
> > + else
> > + dev_info(ci->dev, "otgsc:0x%x, usbsts:0x%x\n",
> > + hw_read_otgsc(ci, ~0),
> > + hw_read_intr_status(ci) &
> > hw_read_intr_enable(ci)
> > + );
> > +
> >
> > return ret;
> > }
> >
If possible, add above code to see which is suspicious interrupts.
--
Best Regards,
Peter Chen
--
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
[GIT PULL] Fixes for v4.8-rc3
Hi Greg, here's the second round of fixes for v4.8-rc3. Nothing really major this time, seems like things are already winding down (famous last words). Let me know if you want anything to be changed. cheers The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468: Linux 4.8-rc3 (2016-08-21 16:14:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git fixes-for-v4.8-rc3 for you to fetch changes up to 6f8245b4e37c2072d3daea24e19dbc0162ffd22c: usb: dwc3: gadget: always decrement by 1 (2016-08-25 12:30:27 +0300) usb: fixes for v4.8-rc3 Few fixes on dwc3 again, the most important being a fix for pm_runtime to make it work with current intel platforms. Other than that, there's a signedness bug fix in fsl udc and some other minor fixes. Baolin Wang (1): usb: gadget: Add the gserial port checking in gs_start_tx() Dan Carpenter (1): usb: gadget: fsl_qe_udc: signedness bug in qe_get_frame() Dinh Nguyen (1): usb: dwc2: Add reset control to dwc2 Felipe Balbi (5): usb: dwc3: pci: runtime_resume child device usb: dwc3: core: allow device to runtime_suspend several times usb: gadget: udc: core: don't starve DMA resources usb: dwc3: debug: fix ep name on trace output usb: dwc3: gadget: always decrement by 1 Nicolas Saenz Julienne (1): usb: dwc3: gadget: don't rely on jiffies while holding spinlock Peter Chen (2): usb: gadget: function: f_eem: socket buffer may be NULL usb: gadget: function: f_rndis: socket buffer may be NULL Wei Yongjun (1): usb: renesas_usbhs: gadget: fix return value check in usbhs_mod_gadget_probe() drivers/usb/dwc2/core.h| 1 + drivers/usb/dwc2/platform.c| 22 ++ drivers/usb/dwc3/core.c| 1 + drivers/usb/dwc3/debug.h | 2 +- drivers/usb/dwc3/dwc3-pci.c| 9 - drivers/usb/dwc3/gadget.c | 11 --- drivers/usb/gadget/function/f_eem.c| 10 +++--- drivers/usb/gadget/function/f_rndis.c | 3 +++ drivers/usb/gadget/function/u_serial.c | 7 ++- drivers/usb/gadget/udc/core.c | 2 +- drivers/usb/gadget/udc/fsl_qe_udc.c| 7 ++- drivers/usb/renesas_usbhs/mod_gadget.c | 2 +- 12 files changed, 57 insertions(+), 20 deletions(-) -- balbi signature.asc Description: PGP signature
Re: [PATCH] usbnet: ax88179_178a: Add support for writing the EEPROM
On Thu, 25 Aug 2016 11:16:36 +0200 Oliver Neukum wrote: > On Wed, 2016-08-24 at 16:40 +0200, Alban Bedel wrote: > > On Wed, 24 Aug 2016 16:30:39 +0200 > > Oliver Neukum wrote: > > > > > On Wed, 2016-08-24 at 15:52 +0200, Alban Bedel wrote: > > > > > + if (block != data) > > > > + kfree(block); > > > > > > And if block == dta, what frees the memory? > > > > In this case this function didn't allocate any memory, so there is > > nothing to free. > > Hi, > > I see. kfree() has a check for NULL, so you could drop the > test, but it doesn't matter much either way. I think you misunderstand something here. data is the buffer passed by the caller and block is a local variable. There is two cases: 1) The data to write is block aligned, then we use the caller buffer as is and set block = data. 2) The requested data is not block aligned, then we kalloc block. In both case the writing loop then use the block pointer. Afterwards we only need to kfree block in case 2, that is when block != data. Alban pgpr98qNZVlpv.pgp Description: OpenPGP digital signature
Re: [PATCH] usbnet: ax88179_178a: Add support for writing the EEPROM
On Thu, 2016-08-25 at 12:07 +0200, Alban Bedel wrote: > On Thu, 25 Aug 2016 11:16:36 +0200 > Oliver Neukum wrote: > > > On Wed, 2016-08-24 at 16:40 +0200, Alban Bedel wrote: > > > On Wed, 24 Aug 2016 16:30:39 +0200 > > > Oliver Neukum wrote: > > > > > > > On Wed, 2016-08-24 at 15:52 +0200, Alban Bedel wrote: > > > > > > > + if (block != data) > > > > > + kfree(block); > > > > > > > > And if block == dta, what frees the memory? > > > > > > In this case this function didn't allocate any memory, so there is > > > nothing to free. > > > > Hi, > > > > I see. kfree() has a check for NULL, so you could drop the > > test, but it doesn't matter much either way. > > I think you misunderstand something here. data is the buffer passed > by the caller and block is a local variable. There is two cases: > > 1) The data to write is block aligned, then we use the caller buffer >as is and set block = data. > 2) The requested data is not block aligned, then we kalloc block. > > In both case the writing loop then use the block pointer. Afterwards > we only need to kfree block in case 2, that is when block != data. Thanks for the clarification. Maybe worth a comment in the code? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT PATCH v2 3/4] usb: dwc2: Properly account for the force mode delays
Hi John,
Am Mittwoch, 24. August 2016, 16:20:01 schrieb John Youn:
> When a force mode bit is set and the IDDIG debounce filter is enabled,
> there is a delay for the forced mode to take effect. This delay is due
> to the IDDIG debounce filter and is variable depending on the platform's
> PHY clock speed. To account for this delay we can poll for the expected
> mode.
>
> On a clear force mode, since we don't know what mode to poll for, delay
> for a fixed 50 ms. This is the maximum delay based on the slowest PHY
> clock speed.
>
> Signed-off-by: John Youn
starting with this patch, I see debounce-failed messages:
[7.934100] usb usb2-port1: connect-debounce failed
on my rk3188. Port is in host-mode and I'll try to investigate further.
One more thing below.
> ---
> drivers/usb/dwc2/core.c | 32 ++--
> 1 file changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index bb903e2..caad6121 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -397,9 +397,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
> * Checks are done in this function to determine whether doing a force
> * would be valid or not.
> *
> - * If a force is done, it requires a 25ms delay to take effect.
> - *
> - * Returns true if the mode was forced.
> + * If a force is done, it requires a IDDIG debounce filter delay if
> + * the filter is configured and enabled. We poll the current mode of
> + * the controller to account for this delay.
> */
> static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
> {
> @@ -434,12 +434,17 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg,
> bool host) gusbcfg |= set;
> dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
>
> - msleep(25);
> - return true;
> + dwc2_wait_for_mode(hsotg, host, 50);
missing a return value and thus resulting in
../drivers/usb/dwc2/core.c: In function ‘dwc2_force_mode’:
../drivers/usb/dwc2/core.c:438:1: warning: control reaches end of non-void
function [-Wreturn-type]
Heiko
--
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: Bug 153551: Kernel panic on Nexus 5X USB unplug while tethering
On 24.08.2016 17:14, Alan Stern wrote: On Wed, 24 Aug 2016, Mathias Nyman wrote: The sleep() worked as it delayed freeing the primary hcd, changing the order to first release usb3 hcd and then usb2 hcd. Does this mean that the patch you already posted is the proper fix? Not sure, still just a step in the right direction. "ab2a4bf USB: don't free bandwidth_mutex too early" seems to solve the other DELL XPS mass storage remove bug. This Nexus 5 case still shows a locking issue after my patch. It ran a 4.7.2 kernel which should have your fix included. Jose Marino, could you try the patch on top of latest 4.8-rc3, just to make sure it's not some old issue? About the locking issue, looks like we end up waiting forever for the device lock mutex: [ 240.854069] INFO: task kworker/u16:31:970 blocked for more than 120 seconds. [ 240.854070] Tainted: GW O4.7.2-1-jose #1 [ 240.854074] Workqueue: kacpi_hotplug acpi_hotplug_work_fn [ 240.854076] Call Trace: [ 240.854077] [] schedule+0x3c/0x90 [ 240.854078] [] schedule_preempt_disabled+0x15/0x20 [ 240.854080] [] __mutex_lock_slowpath+0xce/0x140 [ 240.854082] [] mutex_lock+0x17/0x30 [ 240.854085] [] usb_disconnect+0x51/0x2a0 [usbcore] [ 240.854087] [] usb_remove_hcd+0xc7/0x240 [usbcore] [ 240.854090] [] usb_hcd_pci_remove+0x6f/0x140 [usbcore] [ 240.854091] [] xhci_pci_remove+0x55/0x70 [xhci_pci] (Just one sample, there were many blocked tasks) -Mathias -- 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: [RFT PATCH v2 1/4] usb: dwc2: gadget: Only initialize device if in device mode
Am Mittwoch, 24. August 2016, 16:19:54 schrieb John Youn: > In dwc2_hsotg_udc_start(), don't initialize the controller for device > mode unless we are actually in device mode. > > Signed-off-by: John Youn On rk3188 with both host and (ethernet-)gadget Tested-by: Heiko Stuebner -- 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: [PATCHv6 1/3] usb: USB Type-C connector class
Hi, On Wed, Aug 24, 2016 at 04:08:23PM +0200, Vincent Palatin wrote: > Sorry if I'm making redundant comments with previous discussions, I > might have missed a few threads. > > > On Mon, Aug 22, 2016 at 2:05 PM, Heikki Krogerus > wrote: > > The purpose of USB Type-C connector class is to provide > > unified interface for the user space to get the status and > > basic information about USB Type-C connectors on a system, > > control over data role swapping, and when the port supports > > USB Power Delivery, also control over power role swapping > > and Alternate Modes. > > > > Signed-off-by: Heikki Krogerus > > --- > > Documentation/ABI/testing/sysfs-class-typec | 199 + > > Documentation/usb/typec.txt | 103 +++ > > MAINTAINERS |9 + > > drivers/usb/Kconfig |2 + > > drivers/usb/Makefile|2 + > > drivers/usb/typec/Kconfig |7 + > > drivers/usb/typec/Makefile |1 + > > drivers/usb/typec/typec.c | 1090 > > +++ > > include/linux/usb/typec.h | 260 +++ > > 9 files changed, 1673 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-class-typec > > create mode 100644 Documentation/usb/typec.txt > > create mode 100644 drivers/usb/typec/Kconfig > > create mode 100644 drivers/usb/typec/Makefile > > create mode 100644 drivers/usb/typec/typec.c > > create mode 100644 include/linux/usb/typec.h > > > > diff --git a/Documentation/ABI/testing/sysfs-class-typec > > b/Documentation/ABI/testing/sysfs-class-typec > > new file mode 100644 > > index 000..e6179d3 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-class-typec > > @@ -0,0 +1,199 @@ > > +USB Type-C port devices (eg. /sys/class/typec/usbc0/) > > + > > +What: /sys/class/typec//current_data_role > > +Date: June 2016 > > +Contact: Heikki Krogerus > > +Description: > > + The current USB data role the port is operating in. This > > + attribute can be used for requesting data role swapping on > > the > > + port. > > role swapping is sometimes a long operation. maybe we need to say > explicitly whether the 'write' is synchronous and returns when the > swap has succeeded / failed or asynchronous (and requires polling > current_data_role afterwards to know the result ?) OK. > > + > > + Valid values: > > + - host > > + - device > > the USB workgroup has settled for DFP/UFP rather than host/device ? (I don't think the workgroup has settled on anything.) I already proposed DFP/UFP, but it did not fly. The naming really does not need to reflect the spec exactly, especially since there is no guarantee they will not change the names in future versions of the spec. "host/device", "source/sink" are completely understandable, unlike DRP/UFP. > > > + > > +What: /sys/class/typec//current_power_role > > +Date: June 2016 > > +Contact: Heikki Krogerus > > +Description: > > + The current power role of the port. This attribute can be > > used > > + to request power role swap on the port when the port > > supports > > ditto > > > > + USB Power Delivery. > > + > > + Valid values: > > + - source > > + - sink > > + > > +What: /sys/class/typec//current_vconn_role > > +Date: June 2016 > > +Contact: Heikki Krogerus > > +Description: > > + Shows the current VCONN role of the port. This attribute > > can be > > + used to request VCONN role swap on the port when the port > > + supports USB Power Delivery. > > + > > + Valid values are: > > + - source > > + - sink > > > either we are currently sourcing vconn or not, but even if you are > not, you are probably not a vconn sink either (ie only vconn-powered > accessory are, your usual linux-powered laptop/phone is probably not) It's not relevant to know whether the vconn is being actually used or not here. I'm not sure what's your point? And vconn does not only supply vonn-powered accessories, but powered cables as well. > > + > > +What: /sys/class/typec//power_operation_mode > > +Date: June 2016 > > +Contact: Heikki Krogerus > > +Description: > > + Shows the current power operational mode the port is in. > > + > > + Valid values: > > + - USB - Normal power levels defined in USB specifications > > + - BC1.2 - Power levels defined in Battery Charging > > Specification > > + v1.2 > > + - USB Type-C 1.5A - Higher 1.5A current defined in USB > > Type-C > > + specification. > > + - USB Type-C
Re: [PATCH V3] leds: trigger: Introduce an USB port trigger
On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote:
> On 24 August 2016 at 23:04, Greg KH wrote:
> > On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote:
> >> On 24 August 2016 at 11:22, Greg KH wrote:
> >> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote:
> >> >> +static ssize_t ports_show(struct device *dev, struct device_attribute
> >> >> *attr,
> >> >> + char *buf)
> >> >> +{
> >> >> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> >> >> + struct usbport_trig_data *usbport_data = led_cdev->trigger_data;
> >> >> + struct usbport_trig_port *port;
> >> >> + ssize_t ret = 0;
> >> >> + int len;
> >> >> +
> >> >> + list_for_each_entry(port, &usbport_data->ports, list) {
> >> >> + len = sprintf(buf + ret, "%s\n", port->name);
> >> >> + if (len >= 0)
> >> >> + ret += len;
> >> >> + }
> >> >> +
> >> >> + return ret;
> >> >> +}
> >> >
> >> > sysfs is "one value per file", here you are listing a bunch of things in
> >> > one sysfs file. Please don't do that.
> >>
> >> OK. What do you think about creating "ports" subdirectory and creating
> >> file-per-port in it? Then I'd need to bring back something like
> >> "new_port" and "remove_port". Does it sound OK?
> >
> > Maybe, I don't know. Why is "USB" somehow unique here? Why isn't this
> > the same for PCI slots/ports? pccard? sdcard? thunderbolt?
>
> Good question. I would like to extend this USB port trigger in the
> future by reacting to USB activity. This involves playing with URBs
> and I believe that at that point it'd be getting too much USB specific
> to /rule them all/.
Oh that's never going to work, sorry. USB "activity" happens deep in
USB host controller hardware, not up at the kernel level at all. It's
just too fast, and would take up too much CPU to do it otherwise. Heck,
even old UHCI 1.1 USB controllers did this.
USB "activity" happens all the time, look at a USB bus analyzer if you
want to see what goes on. Teasing out what is "real data" and what is
just "normal bus activity" is impossible at the kernel level, and really
makes no sense at all (your led would just be "on" all the time.)
Are you sure you know how USB works? Writing things like this makes me
really worry...
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 V4] leds: trigger: Introduce an USB port trigger
On Thu, Aug 25, 2016 at 10:03:52AM +0200, Rafał Miłecki wrote:
> +static void usbport_trig_activate(struct led_classdev *led_cdev)
> +{
> + struct usbport_trig_data *usbport_data;
> + int err;
> +
> + usbport_data = kzalloc(sizeof(*usbport_data), GFP_KERNEL);
> + if (!usbport_data)
> + return;
> + usbport_data->led_cdev = led_cdev;
> +
> + /* Storing ports */
> + INIT_LIST_HEAD(&usbport_data->ports);
> + usbport_data->ports_dir = kobject_create_and_add("ports",
> + &led_cdev->dev->kobj);
If you _ever_ find yourself in a driver having to use kobject calls,
it's a HUGE hint that you are doing something wrong.
Hint, you are doing this wrong :)
Use an attribute group if you need a subdirectory in sysfs, using a
"raw" kobject like this hides it from all userspace tools and so no
userspace program can see it (hint, try using libudev to access these
files attached to the device...)
> + if (!usbport_data->ports_dir)
> + goto err_free;
> +
> + /* API for ports management */
> + err = device_create_file(led_cdev->dev, &dev_attr_new_port);
> + if (err)
> + goto err_put_ports;
> + err = device_create_file(led_cdev->dev, &dev_attr_remove_port);
> + if (err)
> + goto err_remove_new_port;
Doesn't this race with userspace and fail? Shouldn't the led core be
creating your leds for you?
> +
> + /* Notifications */
> + usbport_data->nb.notifier_call = usbport_trig_notify,
> + led_cdev->trigger_data = usbport_data;
> + usb_register_notify(&usbport_data->nb);
Don't abuse the USB notifier chain with stuff like this please, is that
really necessary? Why can't your hardware just tell you what USB ports
are in use "out of band"?
> +
> + led_cdev->activated = true;
> + return;
> +
> +err_remove_new_port:
> + device_remove_file(led_cdev->dev, &dev_attr_new_port);
> +err_put_ports:
> + kobject_put(usbport_data->ports_dir);
> +err_free:
> + kfree(usbport_data);
> +}
And again, why is this USB specific? Why can't you use this same
userspace api and codebase for PCI ports? For a sdcard port? For a
thunderbolt port?
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: [GIT PULL] Fixes for v4.8-rc3
On Thu, Aug 25, 2016 at 12:38:18PM +0300, Felipe Balbi wrote: > > Hi Greg, > > here's the second round of fixes for v4.8-rc3. Nothing really major this > time, seems like things are already winding down (famous last words). > > Let me know if you want anything to be changed. > > cheers > > The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468: > > Linux 4.8-rc3 (2016-08-21 16:14:10 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > fixes-for-v4.8-rc3 Now pulled and pushed out, 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: xhci_hcd crash on linux 4.7.0
On 29.07.2016 17:41, Alex Damian wrote: On Fri, Jul 29, 2016 at 2:53 PM, Greg KH wrote: On Fri, Jul 29, 2016 at 10:58:03AM +0100, Alex Damian wrote: Hi Greg, I managed to reproduce with a untainted kernel, see dmesg paste below. The stack seemed corrupted as well ? I refered to it as a crash since after a couple of these issues, the machine hard freezes - I set up a serial console via a USB cable, but I don't get the kernel oops out of the machine. The network is also dead before getting any data. I could not think of any other way to get a console out of a Macbook - any ideas ? There is a progressive level of deterioration going on below, this is why I'm adding multiple pastes. See the obviously invalid pointer 0001 in 3rd paste below. Also, see the protection fault in the last paste. To me, something is trampling all over memory, and it is usb-related. Not good, thanks for reproducing it without the closed kernel drivers. If you disable the list debug kernel option, do you have any problems with the machine? We aren't having any other reports of issues like this at the moment, which makes me worry that it's something unique to your situation/hardware. I strongly suspect it's related to the macbook 12,1 hardware. I haven't been able to reproduce this with other machines, including other macbook versions with the same peripherals. This machine has never been stable in this particular peripheral configuration. I had Apple run all HW diagnostics on the machine, I ran the memcheck to verify that the RAM is ok - all results are clean. The machine is very stable under Mac OSX. And you don't know that it's a USB problem, only that USB is the one that is showing the issue. Anyone could be writing over memory. True. However it seems particularly related to the USB mouse - that's how I manage to reproduce the error. Also, any chance you can use 'git bisect' to track down an offending commit? I'm assuming that this used to work properly and something recently caused the issue, correct? The earliest kernels I've tested are in the 3.3 range. All kernels before 4.7 just lock up. 4.7 is the first kernel where I have meaningful dmesg errors before locking up. As such, there is very little that I can do to bisect :(. Going through xhci related issues that occurred during my vacation. There is one command list related issue fixed in 4.8-rc3, any chance you could try it? Alternatively just add the following patch added to 4.7: 33be126 xhci: always handle "Command Ring Stopped" events Enabling xhci debug could reveal something. echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control -Mathias -- 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: [Umap2][5/11][22b8:2d93] NULL pointer dereference
On Wed, 2016-08-17 at 15:26 +0200, Oliver Neukum wrote: > On Tue, 2016-08-16 at 16:46 +0300, Binyamin Sharet wrote: > > Kernel version: raspberrypi 4.4.6-v7+ #871 > > Driver source file: drivers/usb/class/cdc-acm.c > > Umap2 command line: umap2vsscan -P -s 22b8:2d93 > > Hi, > > could you retest this kernel with the attached fix, > so I know whether it can go into stable? Hi Binyamin, I am sorry to ask, but I got a bit confused with all the patches floating around. Did you test this patch? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Alan, On Wed, 2016-08-24 at 10:10 -0400, Alan Stern wrote: > On Wed, 24 Aug 2016, Ritesh Raj Sarraf wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On Tue, 2016-08-23 at 15:14 -0400, Alan Stern wrote: > > > Okay, good. The "Driver=rtsx_usb" is what I wanted to see. Something > > > funny is going on with that driver -- it claims to support autosuspend > > > but it doesn't ever call usb_mark_last_busy() or > > > usb_autopm_get_interface(). > > > > > > In the meantime, can you post the output from "lsmod"? > > > > > > Also, I'd like to see the output from the following (do this before > > > the device disappears): > > > > > > cd /sys/bus/pci/devices/:00:14.0/usb?/usb?-4/ > > > ls -lR > > > > > > > Please find the asked output at the following links: > > > > https://people.debian.org/~rrs/tmp/usb-ls-lR.txt > > https://people.debian.org/~rrs/tmp/lsmod-usb.txt > > Do you happen to know which driver is being used: the memstick > (rtsx_usb_ms) or mmc (rtsx_usb_sdmmc) driver? I suppose this may > depend on what type of card you insert in the reader. > I think it is the rtsx_usb_sdmmc which is in use. I removed the rtsx_usb_ms kernel module and still was able to access the sdcard. rrs@learner:~$ lsmod | grep usb_ms 2016-08-25 / 18:45:52 ♒♒♒ ☹ => 1 rrs@learner:~$ lsmod | grep usb_sd rtsx_usb_sdmmc 24576 0 rtsx_usb 24576 1 rtsx_usb_sdmmc mmc_core 135168 4 mmc_block,sdhci,sdhci_acpi,rtsx_usb_sdmmc 2016-08-25 / 18:45:55 ♒♒♒ ☺ The interesting bit is that when I enter the adapter into the reader, I get the following error 5 times, and then it can access the card. [ 496.822613] mmc0: tuning execution failed: -22 [ 496.822629] mmc0: error -22 whilst initialising SD card [ 501.980908] mmc0: tuning execution failed: -22 [ 501.980922] mmc0: error -22 whilst initialising SD card [ 507.119953] mmc0: tuning execution failed: -22 [ 507.119968] mmc0: error -22 whilst initialising SD card [ 513.148143] mmc0: tuning execution failed: -22 [ 513.148157] mmc0: error -22 whilst initialising SD card [ 518.702215] mmc0: tuning execution failed: -22 [ 518.70] mmc0: error -22 whilst initialising SD card [ 524.081122] mmc0: new ultra high speed SDR50 SDHC card at address 0002 [ 524.082596] mmcblk0: mmc0:0002 NCard 14.9 GiB [ 524.084240] mmcblk0: p1 [ 524.306434] FAT-fs (mmcblk0p1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 584.89] mmc0: card 0002 removed [ 623.662587] mmc0: tuning execution failed: -22 [ 623.662603] mmc0: error -22 whilst initialising SD card [ 629.373424] mmc0: tuning execution failed: -22 [ 629.373439] mmc0: error -22 whilst initialising SD card [ 634.544907] mmc0: tuning execution failed: -22 [ 634.544914] mmc0: error -22 whilst initialising SD card [ 641.375119] mmc0: tuning execution failed: -22 [ 641.375134] mmc0: error -22 whilst initialising SD card [ 646.725767] mmc0: tuning execution failed: -22 [ 646.725782] mmc0: error -22 whilst initialising SD card [ 651.305528] mmc0: new ultra high speed SDR50 SDHC card at address 0002 [ 651.306491] mmcblk0: mmc0:0002 NCard 14.9 GiB [ 651.307906] mmcblk0: p1 [ 651.536923] FAT-fs (mmcblk0p1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! 2016-08-25 / 18:45:04 ♒♒♒ ☺ > > I have a question though. For power saving, I use Laptop Mode Tools. Based > on > > power state (AC or BATT), it enables/disables power saving knobs. > > > > https://github.com/rickysarraf/laptop-mode-tools > > > > Since I suspected the same problem (incapable of LPM) I have had this device > > blacklisted in Laptop Mode Tools. Here are the attributes for this > particular > > device, while on battery. > > > > rrs@learner:/sys/bus/usb/devices/1-4$ cat power/autosuspend > > 0 > > 2016-08-24 / 14:47:07 ♒♒♒ ☺ > > rrs@learner:/sys/bus/usb/devices/1-4$ cat power/control > > on > > 2016-08-24 / 14:47:34 ♒♒♒ ☺ > > rrs@learner:/sys/bus/usb/devices/1-4$ cat power/level > > on > > 2016-08-24 / 14:47:38 ♒♒♒ ☺ > > > > > > While I write this, the bug hasn't triggered again. I think what may have > > happened is this: > > > > * OS Boots > > * Goes on battery > > * LMT sets OS to power saving mode, but blacklists device 1-4 > > * Eventually, the device resets (device/driver bug?) > > * Upon reset, driver re-initializes the power saving values to default (?). > > At this time LMT will not re-apply any settings, because it only gets > invoked > > when a power_supply state change is sensed, i.e. ON_BATT or ON_AC. > > That sounds like a bug in LMT. It ought to handle hotplug events. You > could report that to the authors. > LMT does handle the events. But given that this device was troubling a lot, I had the device blacklisted for any power savings. With your patch applied, the initial errors mes
Re: [Umap2][5/11][22b8:2d93] NULL pointer dereference
> > On 25 Aug 2016, at 15:59, Oliver Neukum wrote: > > On Wed, 2016-08-17 at 15:26 +0200, Oliver Neukum wrote: >> On Tue, 2016-08-16 at 16:46 +0300, Binyamin Sharet wrote: >>> Kernel version: raspberrypi 4.4.6-v7+ #871 >>> Driver source file: drivers/usb/class/cdc-acm.c >>> Umap2 command line: umap2vsscan -P -s 22b8:2d93 >> >> Hi, >> >> could you retest this kernel with the attached fix, >> so I know whether it can go into stable? > > Hi Binyamin, I am sorry to ask, but I got a bit confused > with all the patches floating around. Did you test this patch? > > Regards > Oliver > > It’s a good thing you asked, as I forgot to test this one… Just to be sure - which tag should I use for testing this one? Is v4.4 OK? Thanks, Binyamin Sharet Cisco, STARE-C
Re: [Umap2][5/11][22b8:2d93] NULL pointer dereference
On Thu, 2016-08-25 at 13:53 +, Binyamin Sharet (bsharet) wrote: > > > It’s a good thing you asked, as I forgot to test this one… > > Just to be sure - which tag should I use for testing this one? > Is v4.4 OK? Yes, perfect. Thanks Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
On Thu, 25 Aug 2016, Jacek Anaszewski wrote: > I'd see it as follows: > > #cat available_ports > #1-1 1-2 2-1 > > #echo "1-1" > new_port > > #cat observed_ports > #1-1 > > #echo "2-1" > new_port > > #cat observed_ports > #1-1 2-1 > > We've already had few discussions about the sysfs designs trying > to break the one-value-per-file rule for LED class device, and > there was always strong resistance against. This scheme has multiple values in both the available_ports and observed_ports files. :-( Not that I have any better suggestions... > >> Also a description of the device connected to the port would be a nice > >> feature, however I am not certain about the feasibility thereof. > > > > What kind of description do you mean? Where should it be used / where > > should it appear? > > > > Product name/symbol. Actually it should be USB subsystem responsibility > to provide the means for querying the product name by port id, if it > is possible at all. cat /sys/bus/usb/devices/PORT/product cat /sys/bus/usb/devices/PORT/manufacturer These will work if there is a device registered under PORT. 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: [Umap2][5/11][22b8:2d93] NULL pointer dereference
> On 25 Aug 2016, at 17:24, Oliver Neukum wrote: > > On Thu, 2016-08-25 at 13:53 +, Binyamin Sharet (bsharet) wrote: >>> > >> It’s a good thing you asked, as I forgot to test this one… >> >> Just to be sure - which tag should I use for testing this one? >> Is v4.4 OK? > > Yes, perfect. > > Thanks > Oliver > > Hi Oliver, It will take me some time to test it on v4.4.6-v7, so I have tried applying the patch to v4.4 but it failed in the 4th hunk (line 47). Please advise, should I: - manually edit the file on v4.4 and retest? - checkout a specific commit and apply the patch on it? if so, which commit? - wait for a patch to v4.4 from you? - something else? Thanks, Binyamin Sharet Cisco, STARE-C
[PATCH] usb-storage: MAINTAINERS: Alan Stern is the new maintainer
At Matt Dharm's request, I am taking over maintainership of the usb-storage driver. Signed-off-by: Alan Stern CC: Matthew Dharm --- [as1811] MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: usb-4.x/MAINTAINERS === --- usb-4.x.orig/MAINTAINERS +++ usb-4.x/MAINTAINERS @@ -12163,7 +12163,7 @@ S: Maintained F: drivers/net/usb/lan78xx.* USB MASS STORAGE DRIVER -M: Matthew Dharm +M: Alan Stern L: linux-usb@vger.kernel.org L: usb-stor...@lists.one-eyed-alien.net S: Maintained -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb-storage: MAINTAINERS: Alan Stern is the new maintainer
On Thu, Aug 25, 2016 at 8:30 AM, Alan Stern wrote: > At Matt Dharm's request, I am taking over maintainership of the > usb-storage driver. Alan is being too modest. I think he's been the de facto maintainer already for quite some time; he's certainly much more active with responding to questions and bug reports on the mailing lists. This change just makes it official. It's something I've been thinking about doing for a long time, and a recent e-mail from a project noting that there are maintainers who have not submitted any patches in at least 3 years finally got me off-the-bubble. > Signed-off-by: Alan Stern Acked-by: Matthew Dharm > > --- > > > [as1811] > > > MAINTAINERS |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: usb-4.x/MAINTAINERS > === > --- usb-4.x.orig/MAINTAINERS > +++ usb-4.x/MAINTAINERS > @@ -12163,7 +12163,7 @@ S: Maintained > F: drivers/net/usb/lan78xx.* > > USB MASS STORAGE DRIVER > -M: Matthew Dharm > +M: Alan Stern > L: linux-usb@vger.kernel.org > L: usb-stor...@lists.one-eyed-alien.net > S: Maintained > -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux -- 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: Bug 153551: Kernel panic on Nexus 5X USB unplug while tethering
On 08/25/2016 05:09 AM, Mathias Nyman wrote: On 24.08.2016 17:14, Alan Stern wrote: On Wed, 24 Aug 2016, Mathias Nyman wrote: The sleep() worked as it delayed freeing the primary hcd, changing the order to first release usb3 hcd and then usb2 hcd. Does this mean that the patch you already posted is the proper fix? Not sure, still just a step in the right direction. "ab2a4bf USB: don't free bandwidth_mutex too early" seems to solve the other DELL XPS mass storage remove bug. This Nexus 5 case still shows a locking issue after my patch. It ran a 4.7.2 kernel which should have your fix included. Jose Marino, could you try the patch on top of latest 4.8-rc3, just to make sure it's not some old issue? About the locking issue, looks like we end up waiting forever for the device lock mutex: [ 240.854069] INFO: task kworker/u16:31:970 blocked for more than 120 seconds. [ 240.854070] Tainted: GW O4.7.2-1-jose #1 [ 240.854074] Workqueue: kacpi_hotplug acpi_hotplug_work_fn [ 240.854076] Call Trace: [ 240.854077] [] schedule+0x3c/0x90 [ 240.854078] [] schedule_preempt_disabled+0x15/0x20 [ 240.854080] [] __mutex_lock_slowpath+0xce/0x140 [ 240.854082] [] mutex_lock+0x17/0x30 [ 240.854085] [] usb_disconnect+0x51/0x2a0 [usbcore] [ 240.854087] [] usb_remove_hcd+0xc7/0x240 [usbcore] [ 240.854090] [] usb_hcd_pci_remove+0x6f/0x140 [usbcore] [ 240.854091] [] xhci_pci_remove+0x55/0x70 [xhci_pci] (Just one sample, there were many blocked tasks) -Mathias I tried the patch on top of 4.8-rc3. Reboot, suspend/resume, plug in phone and tell it to tether. Again the tether connection did not work, dhcp client doesn't get a response and times out. Then I unplug the phone and everything seems to be handled nicely. No oops or panics or hung tasks. I attach the dmesg. Even though the patch seems to fix the trouble when unplugging, it still does nothing about the tether connection not working after a suspend/resume cycle. Do you think this is a different bug altogether? Any ideas how to trouble shoot that one? dmesg-Nyman-4.8rc3.log.gz Description: application/gzip
[GIT PULL] USB-serial fixes for v4.8-rc4
Hi Greg, Here's a second set of fixes for 4.8-rc. All have been in linux-next. Thanks, Johan The following changes since commit 647024a7df36014bbc4479d92d88e6b77c0afcf6: USB: serial: fix memleak in driver-registration error path (2016-08-08 13:41:17 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-4.8-rc4 for you to fetch changes up to 40d9c32525cba79130612650b1abc47c0c0f19a8: USB: serial: option: add WeTelecom 0x6802 and 0x6803 products (2016-08-24 14:13:40 +0200) USB-serial fixes for v4.8-rc4 Here are a couple of fixes for non-atomic allocations in write paths, and some new option device ids. Signed-off-by: Johan Hovold Aleksandr Makarov (2): USB: serial: option: add WeTelecom WM-D200 USB: serial: option: add WeTelecom 0x6802 and 0x6803 products Alexey Khoroshilov (2): USB: serial: mos7720: fix non-atomic allocation in write path USB: serial: mos7840: fix non-atomic allocation in write path drivers/usb/serial/mos7720.c | 2 +- drivers/usb/serial/mos7840.c | 4 ++-- drivers/usb/serial/option.c | 9 + 3 files changed, 12 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: chipidea: hdc: kernel panic during shutdown
Hi,
> Peter Chen hat am 25. August 2016 um 11:16
> geschrieben:
>
>
> On Thu, Aug 25, 2016 at 08:27:03AM +0200, Stefan Wahren wrote:
> > Am 25.08.2016 um 08:44 schrieb Peter Chen:
> > > On Thu, Aug 25, 2016 at 07:06:12AM +0200, Stefan Wahren wrote:
> > >> Hi Alan,
> > >>
> > >> i tried the following patch:
> > >> --- a/drivers/usb/chipidea/host.c
> > >> +++ b/drivers/usb/chipidea/host.c
> > >> @@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
> > >>
> > >> if (hcd) {
> > >> usb_remove_hcd(hcd);
> > >> + ci_role_stop(ci);
> > >> + synchronize_irq(ci->irq);
> > > Would you please just add below line to see if this problem can be
> > > fixed?
> > > + ci->role = CI_ROLE_END;
> > >
> > > When ci->role is CI_ROLE_END, neither host nor device interrupt handler
> > > will run.
> >
> > I would add this before synchronize_irq() as Alan suggested.
i replaced my ci_role_stop(ci) with ci->role = CI_ROLE_END and the panic
disappear:
[ 114.98] ci_hdrc ci_hdrc.0: remove, state 1
[ 114.99] usb usb1: USB disconnect, device number 1
[ 115.00] usb 1-1: USB disconnect, device number 2
[ 115.00] usb 1-1.1: USB disconnect, device number 3
[ 115.03] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-ci_hdrc.0-1.1,
smsc95xx USB 2.0 Ethernet
[ 115.22] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[ 115.23] otgsc:0x4e20, usbsts:0x0
[ 115.24] reboot: System halted
Regards
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: Fix locking errors for host only mode
Hi, On Thu, Aug 18, 2016 at 03:40:38PM -0700, Tony Lindgren wrote: > If we have USB gadgets disabled and USB_MUSB_HOST set, we get > errors "possible irq lock inverssion dependency detected" > errors during boot. > > Let's fix the issue by adding start_musb flag and start > the controller after we're out of the spinlock protected > section. > > Reported-by: Ladislav Michl > Tested-by: Ladislav Michl > Signed-off-by: Tony Lindgren Signed-off-by: Bin Liu Regards, -Bin. > --- > drivers/usb/musb/musb_virthub.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c > index 192248f..fe08e77 100644 > --- a/drivers/usb/musb/musb_virthub.c > +++ b/drivers/usb/musb/musb_virthub.c > @@ -290,6 +290,7 @@ int musb_hub_control( > u32 temp; > int retval = 0; > unsigned long flags; > + boolstart_musb = false; > > spin_lock_irqsave(&musb->lock, flags); > > @@ -390,7 +391,7 @@ int musb_hub_control( >* logic relating to VBUS power-up. >*/ > if (!hcd->self.is_b_host && musb_has_gadget(musb)) > - musb_start(musb); > + start_musb = true; > break; > case USB_PORT_FEAT_RESET: > musb_port_reset(musb, true); > @@ -451,5 +452,9 @@ error: > retval = -EPIPE; > } > spin_unlock_irqrestore(&musb->lock, flags); > + > + if (start_musb) > + musb_start(musb); > + > return retval; > } > -- > 2.8.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: [RFT PATCH v2 2/4] usb: dwc2: Add delay to core soft reset
Am Mittwoch, 24. August 2016, 16:19:58 schrieb John Youn: > Add a delay to the core soft reset function to account for the IDDIG > debounce filter. > > If the current mode is host, either due to the force mode bit being > set (which persists after core reset) or the connector id pin, a core > soft reset will temporarily reset the mode to device and a delay from > the IDDIG debounce filter will occur before going back to host mode. > > Signed-off-by: John Youn on a rk3188 in host and device mode and on rk3036 + rk3368 in host-mode Tested-by: Heiko Stuebner -- 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 01/44] usb: atm: cxacru: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/atm/cxacru.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index 18b281d73a39ee..f9fe86b6f7b5b6 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -1139,10 +1139,8 @@ static int cxacru_bind(struct usbatm_data
*usbatm_instance,
/* instance init */
instance = kzalloc(sizeof(*instance), GFP_KERNEL);
- if (!instance) {
- usb_dbg(usbatm_instance, "cxacru_bind: no memory for instance
data\n");
+ if (!instance)
return -ENOMEM;
- }
instance->usbatm = usbatm_instance;
instance->modem_type = (struct cxacru_modem_type *) id->driver_info;
--
2.9.3
--
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 04/44] usb: atm: usbatm: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/atm/usbatm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index 5e4f46c5a30046..4dec9df8764b9a 100644
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm/usbatm.c
@@ -819,7 +819,6 @@ static int usbatm_atm_open(struct atm_vcc *vcc)
new = kzalloc(sizeof(struct usbatm_vcc_data), GFP_KERNEL);
if (!new) {
- atm_err(instance, "%s: no memory for vcc_data!\n", __func__);
ret = -ENOMEM;
goto fail;
}
@@ -1032,10 +1031,8 @@ int usbatm_usb_probe(struct usb_interface *intf, const
struct usb_device_id *id,
/* instance init */
instance = kzalloc(sizeof(*instance) + sizeof(struct urb *) *
(num_rcv_urbs + num_snd_urbs), GFP_KERNEL);
- if (!instance) {
- dev_err(dev, "%s: no memory for instance data!\n", __func__);
+ if (!instance)
return -ENOMEM;
- }
/* public fields */
@@ -1150,7 +1147,6 @@ int usbatm_usb_probe(struct usb_interface *intf, const
struct usb_device_id *id,
/* zero the tx padding to avoid leaking information */
buffer = kzalloc(channel->buf_size, GFP_KERNEL);
if (!buffer) {
- dev_err(dev, "%s: no memory for buffer %d!\n",
__func__, i);
error = -ENOMEM;
goto fail_unbind;
}
@@ -1181,7 +1177,6 @@ int usbatm_usb_probe(struct usb_interface *intf, const
struct usb_device_id *id,
instance->cell_buf = kmalloc(instance->rx_channel.stride, GFP_KERNEL);
if (!instance->cell_buf) {
- dev_err(dev, "%s: no memory for cell buffer!\n", __func__);
error = -ENOMEM;
goto fail_unbind;
}
--
2.9.3
--
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 34/44] usb: musb: am35x: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/musb/am35x.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index c41fe588d14d97..c14577dbedf71a 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -474,10 +474,8 @@ static int am35x_probe(struct platform_device *pdev)
int ret = -ENOMEM;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
- if (!glue) {
- dev_err(&pdev->dev, "failed to allocate glue context\n");
+ if (!glue)
goto err0;
- }
phy_clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(phy_clk)) {
--
2.9.3
--
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 44/44] usb: wusbcore: wa-nep: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/wusbcore/wa-nep.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/wusbcore/wa-nep.c b/drivers/usb/wusbcore/wa-nep.c
index 6140100ad50e41..ed4622279c63c0 100644
--- a/drivers/usb/wusbcore/wa-nep.c
+++ b/drivers/usb/wusbcore/wa-nep.c
@@ -271,11 +271,8 @@ int wa_nep_create(struct wahc *wa, struct usb_interface
*iface)
epd = &iface->cur_altsetting->endpoint[0].desc;
wa->nep_buffer_size = 1024;
wa->nep_buffer = kmalloc(wa->nep_buffer_size, GFP_KERNEL);
- if (wa->nep_buffer == NULL) {
- dev_err(dev,
- "Unable to allocate notification's read buffer\n");
+ if (!wa->nep_buffer)
goto error_nep_buffer;
- }
wa->nep_urb = usb_alloc_urb(0, GFP_KERNEL);
if (wa->nep_urb == NULL)
goto error_urb_alloc;
--
2.9.3
--
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 16/44] usb: host: uhci-hcd: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/host/uhci-hcd.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index a7de8e8bb4582b..5d3d914ab4fb44 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -601,11 +601,8 @@ static int uhci_start(struct usb_hcd *hcd)
uhci->frame_cpu = kcalloc(UHCI_NUMFRAMES, sizeof(*uhci->frame_cpu),
GFP_KERNEL);
- if (!uhci->frame_cpu) {
- dev_err(uhci_dev(uhci),
- "unable to allocate memory for frame pointers\n");
+ if (!uhci->frame_cpu)
goto err_alloc_frame_cpu;
- }
uhci->td_pool = dma_pool_create("uhci_td", uhci_dev(uhci),
sizeof(struct uhci_td), 16, 0);
--
2.9.3
--
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 40/44] usb: storage: sddr09: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/storage/sddr09.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/storage/sddr09.c b/drivers/usb/storage/sddr09.c
index c5797fa2125e94..3aeaa536c44f9e 100644
--- a/drivers/usb/storage/sddr09.c
+++ b/drivers/usb/storage/sddr09.c
@@ -766,10 +766,8 @@ sddr09_read_data(struct us_data *us,
len = min(sectors, (unsigned int) info->blocksize) * info->pagesize;
buffer = kmalloc(len, GFP_NOIO);
- if (buffer == NULL) {
- printk(KERN_WARNING "sddr09_read_data: Out of memory\n");
+ if (!buffer)
return -ENOMEM;
- }
// This could be made much more efficient by checking for
// contiguous LBA's. Another exercise left to the student.
@@ -1004,10 +1002,8 @@ sddr09_write_data(struct us_data *us,
pagelen = (1 << info->pageshift) + (1 << CONTROL_SHIFT);
blocklen = (pagelen << info->blockshift);
blockbuffer = kmalloc(blocklen, GFP_NOIO);
- if (!blockbuffer) {
- printk(KERN_WARNING "sddr09_write_data: Out of memory\n");
+ if (!blockbuffer)
return -ENOMEM;
- }
/*
* Since we don't write the user data directly to the device,
@@ -1017,8 +1013,7 @@ sddr09_write_data(struct us_data *us,
len = min(sectors, (unsigned int) info->blocksize) * info->pagesize;
buffer = kmalloc(len, GFP_NOIO);
- if (buffer == NULL) {
- printk(KERN_WARNING "sddr09_write_data: Out of memory\n");
+ if (!buffer) {
kfree(blockbuffer);
return -ENOMEM;
}
@@ -1241,8 +1236,7 @@ sddr09_read_map(struct us_data *us) {
alloc_blocks = min(numblocks, SDDR09_READ_MAP_BUFSZ >> CONTROL_SHIFT);
alloc_len = (alloc_blocks << CONTROL_SHIFT);
buffer = kmalloc(alloc_len, GFP_NOIO);
- if (buffer == NULL) {
- printk(KERN_WARNING "sddr09_read_map: out of memory\n");
+ if (!buffer) {
result = -1;
goto done;
}
--
2.9.3
--
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 12/44] usb: gadget: udc: goku_udc: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/gadget/udc/goku_udc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/goku_udc.c
b/drivers/usb/gadget/udc/goku_udc.c
index d2205d9e0c8b43..1400415fe67ac8 100644
--- a/drivers/usb/gadget/udc/goku_udc.c
+++ b/drivers/usb/gadget/udc/goku_udc.c
@@ -1767,8 +1767,7 @@ static int goku_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
/* alloc, and start init */
dev = kzalloc (sizeof *dev, GFP_KERNEL);
- if (dev == NULL){
- pr_debug("enomem %s\n", pci_name(pdev));
+ if (!dev) {
retval = -ENOMEM;
goto err;
}
--
2.9.3
--
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 28/44] usb: misc: lvstest: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/lvstest.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/misc/lvstest.c b/drivers/usb/misc/lvstest.c
index 961faae62ea087..af2952b918b843 100644
--- a/drivers/usb/misc/lvstest.c
+++ b/drivers/usb/misc/lvstest.c
@@ -247,10 +247,8 @@ static ssize_t get_dev_desc_store(struct device *dev,
int ret;
descriptor = kmalloc(sizeof(*descriptor), GFP_KERNEL);
- if (!descriptor) {
- dev_err(dev, "failed to allocate descriptor memory\n");
+ if (!descriptor)
return -ENOMEM;
- }
udev = create_lvs_device(intf);
if (!udev) {
--
2.9.3
--
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 42/44] usb: wusbcore: crypto: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/wusbcore/crypto.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/wusbcore/crypto.c b/drivers/usb/wusbcore/crypto.c
index 33acd1599e99e9..79b2b628066d81 100644
--- a/drivers/usb/wusbcore/crypto.c
+++ b/drivers/usb/wusbcore/crypto.c
@@ -229,10 +229,8 @@ static int wusb_ccm_mac(struct crypto_skcipher *tfm_cbc,
zero_padding = sizeof(struct aes_ccm_block) - zero_padding;
dst_size = blen + sizeof(b0) + sizeof(b1) + zero_padding;
dst_buf = kzalloc(dst_size, GFP_KERNEL);
- if (dst_buf == NULL) {
- printk(KERN_ERR "E: can't alloc destination buffer\n");
+ if (!dst_buf)
goto error_dst_buf;
- }
memset(iv, 0, sizeof(iv));
--
2.9.3
--
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 32/44] usb: misc: uss720: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/uss720.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/misc/uss720.c b/drivers/usb/misc/uss720.c
index 256d02da444d0f..356d312add5779 100644
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -150,10 +150,8 @@ static struct uss720_async_request
*submit_async_request(struct parport_uss720_p
if (!usbdev)
return NULL;
rq = kzalloc(sizeof(struct uss720_async_request), mem_flags);
- if (!rq) {
- dev_err(&usbdev->dev, "submit_async_request out of memory\n");
+ if (!rq)
return NULL;
- }
kref_init(&rq->ref_count);
INIT_LIST_HEAD(&rq->asynclist);
init_completion(&rq->compl);
--
2.9.3
--
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 09/44] usb: core: urb: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/core/urb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index c601e25b609fb5..a9039696476e68 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -68,10 +68,8 @@ struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags)
urb = kmalloc(sizeof(struct urb) +
iso_packets * sizeof(struct usb_iso_packet_descriptor),
mem_flags);
- if (!urb) {
- printk(KERN_ERR "alloc_urb: kmalloc failed\n");
+ if (!urb)
return NULL;
- }
usb_init_urb(urb);
return urb;
}
--
2.9.3
--
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 14/44] usb: host: fhci-hcd: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/host/fhci-hcd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index 0960f41f945aba..55a0ae6f2d7430 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -310,10 +310,8 @@ static struct fhci_usb *fhci_create_lld(struct fhci_hcd
*fhci)
/* allocate memory for SCC data structure */
usb = kzalloc(sizeof(*usb), GFP_KERNEL);
- if (!usb) {
- fhci_err(fhci, "no memory for SCC data struct\n");
+ if (!usb)
return NULL;
- }
usb->fhci = fhci;
usb->hc_list = fhci->hc_list;
--
2.9.3
--
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 37/44] usb: renesas_usbhs: mod_host: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/renesas_usbhs/mod_host.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/mod_host.c
b/drivers/usb/renesas_usbhs/mod_host.c
index 3bf0b72eb359f1..165e81bfd93a66 100644
--- a/drivers/usb/renesas_usbhs/mod_host.c
+++ b/drivers/usb/renesas_usbhs/mod_host.c
@@ -166,14 +166,10 @@ static struct usbhsh_request *usbhsh_ureq_alloc(struct
usbhsh_hpriv *hpriv,
gfp_t mem_flags)
{
struct usbhsh_request *ureq;
- struct usbhs_priv *priv = usbhsh_hpriv_to_priv(hpriv);
- struct device *dev = usbhs_priv_to_dev(priv);
ureq = kzalloc(sizeof(struct usbhsh_request), mem_flags);
- if (!ureq) {
- dev_err(dev, "ureq alloc fail\n");
+ if (!ureq)
return NULL;
- }
usbhs_pkt_init(&ureq->pkt);
ureq->urb = urb;
@@ -388,10 +384,8 @@ static int usbhsh_endpoint_attach(struct usbhsh_hpriv
*hpriv,
unsigned long flags;
uep = kzalloc(sizeof(struct usbhsh_ep), mem_flags);
- if (!uep) {
- dev_err(dev, "usbhsh_ep alloc fail\n");
+ if (!uep)
return -ENOMEM;
- }
/ spin lock /
usbhs_lock(priv, flags);
--
2.9.3
--
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 24/44] usb: misc: idmouse: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/idmouse.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/misc/idmouse.c b/drivers/usb/misc/idmouse.c
index 5105397e62fc76..2975e80b7a56f9 100644
--- a/drivers/usb/misc/idmouse.c
+++ b/drivers/usb/misc/idmouse.c
@@ -366,7 +366,6 @@ static int idmouse_probe(struct usb_interface *interface,
kmalloc(IMGSIZE + dev->bulk_in_size, GFP_KERNEL);
if (!dev->bulk_in_buffer) {
- dev_err(&interface->dev, "Unable to allocate input
buffer.\n");
idmouse_delete(dev);
return -ENOMEM;
}
--
2.9.3
--
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 22/44] usb: misc: cytherm: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/cytherm.c | 32
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/misc/cytherm.c b/drivers/usb/misc/cytherm.c
index 9bab1a33bc16b6..9d8bb8dacdcd11 100644
--- a/drivers/usb/misc/cytherm.c
+++ b/drivers/usb/misc/cytherm.c
@@ -101,10 +101,8 @@ static ssize_t set_brightness(struct device *dev, struct
device_attribute *attr,
int retval;
buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer) {
- dev_err(&cytherm->udev->dev, "out of memory\n");
+ if (!buffer)
return 0;
- }
cytherm->brightness = simple_strtoul(buf, NULL, 10);
@@ -148,10 +146,8 @@ static ssize_t show_temp(struct device *dev, struct
device_attribute *attr, char
int temp, sign;
buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer) {
- dev_err(&cytherm->udev->dev, "out of memory\n");
+ if (!buffer)
return 0;
- }
/* read temperature */
retval = vendor_command(cytherm->udev, READ_RAM, TEMP, 0, buffer, 8);
@@ -192,10 +188,8 @@ static ssize_t show_button(struct device *dev, struct
device_attribute *attr, ch
unsigned char *buffer;
buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer) {
- dev_err(&cytherm->udev->dev, "out of memory\n");
+ if (!buffer)
return 0;
- }
/* check button */
retval = vendor_command(cytherm->udev, READ_RAM, BUTTON, 0, buffer, 8);
@@ -230,10 +224,8 @@ static ssize_t show_port0(struct device *dev, struct
device_attribute *attr, cha
unsigned char *buffer;
buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer) {
- dev_err(&cytherm->udev->dev, "out of memory\n");
+ if (!buffer)
return 0;
- }
retval = vendor_command(cytherm->udev, READ_PORT, 0, 0, buffer, 8);
if (retval)
@@ -257,10 +249,8 @@ static ssize_t set_port0(struct device *dev, struct
device_attribute *attr, cons
int tmp;
buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer) {
- dev_err(&cytherm->udev->dev, "out of memory\n");
+ if (!buffer)
return 0;
- }
tmp = simple_strtoul(buf, NULL, 10);
@@ -290,10 +280,8 @@ static ssize_t show_port1(struct device *dev, struct
device_attribute *attr, cha
unsigned char *buffer;
buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer) {
- dev_err(&cytherm->udev->dev, "out of memory\n");
+ if (!buffer)
return 0;
- }
retval = vendor_command(cytherm->udev, READ_PORT, 1, 0, buffer, 8);
if (retval)
@@ -317,10 +305,8 @@ static ssize_t set_port1(struct device *dev, struct
device_attribute *attr, cons
int tmp;
buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer) {
- dev_err(&cytherm->udev->dev, "out of memory\n");
+ if (!buffer)
return 0;
- }
tmp = simple_strtoul(buf, NULL, 10);
@@ -351,10 +337,8 @@ static int cytherm_probe(struct usb_interface *interface,
int retval = -ENOMEM;
dev = kzalloc (sizeof(struct usb_cytherm), GFP_KERNEL);
- if (dev == NULL) {
- dev_err (&interface->dev, "Out of memory\n");
+ if (!dev)
goto error_mem;
- }
dev->udev = usb_get_dev(udev);
--
2.9.3
--
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 20/44] usb: misc: appledisplay: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/appledisplay.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c
index f7c48703347fb7..0b2617fe1c9b6f 100644
--- a/drivers/usb/misc/appledisplay.c
+++ b/drivers/usb/misc/appledisplay.c
@@ -239,7 +239,6 @@ static int appledisplay_probe(struct usb_interface *iface,
pdata = kzalloc(sizeof(struct appledisplay), GFP_KERNEL);
if (!pdata) {
retval = -ENOMEM;
- dev_err(&iface->dev, "Out of memory\n");
goto error;
}
@@ -253,8 +252,6 @@ static int appledisplay_probe(struct usb_interface *iface,
pdata->msgdata = kmalloc(ACD_MSG_BUFFER_LEN, GFP_KERNEL);
if (!pdata->msgdata) {
retval = -ENOMEM;
- dev_err(&iface->dev,
- "Allocating buffer for control messages failed\n");
goto error;
}
--
2.9.3
--
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 26/44] usb: misc: ldusb: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/ldusb.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c
index 84890791c2f830..9ca595632f171c 100644
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -658,10 +658,8 @@ static int ld_usb_probe(struct usb_interface *intf, const
struct usb_device_id *
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
- if (dev == NULL) {
- dev_err(&intf->dev, "Out of memory\n");
+ if (!dev)
goto exit;
- }
mutex_init(&dev->mutex);
spin_lock_init(&dev->rbsl);
dev->intf = intf;
@@ -674,10 +672,8 @@ static int ld_usb_probe(struct usb_interface *intf, const
struct usb_device_id *
(le16_to_cpu(udev->descriptor.idProduct) ==
USB_DEVICE_ID_LD_COM3LAB)) &&
(le16_to_cpu(udev->descriptor.bcdDevice) <= 0x103)) {
buffer = kmalloc(256, GFP_KERNEL);
- if (buffer == NULL) {
- dev_err(&intf->dev, "Couldn't allocate string
buffer\n");
+ if (!buffer)
goto error;
- }
/* usb_string makes SETUP+STALL to leave always ControlReadLoop
*/
usb_string(udev, 255, buffer, 256);
kfree(buffer);
@@ -704,25 +700,19 @@ static int ld_usb_probe(struct usb_interface *intf, const
struct usb_device_id *
dev->interrupt_in_endpoint_size =
usb_endpoint_maxp(dev->interrupt_in_endpoint);
dev->ring_buffer =
kmalloc(ring_buffer_size*(sizeof(size_t)+dev->interrupt_in_endpoint_size),
GFP_KERNEL);
- if (!dev->ring_buffer) {
- dev_err(&intf->dev, "Couldn't allocate ring_buffer\n");
+ if (!dev->ring_buffer)
goto error;
- }
dev->interrupt_in_buffer = kmalloc(dev->interrupt_in_endpoint_size,
GFP_KERNEL);
- if (!dev->interrupt_in_buffer) {
- dev_err(&intf->dev, "Couldn't allocate interrupt_in_buffer\n");
+ if (!dev->interrupt_in_buffer)
goto error;
- }
dev->interrupt_in_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->interrupt_in_urb)
goto error;
dev->interrupt_out_endpoint_size = dev->interrupt_out_endpoint ?
usb_endpoint_maxp(dev->interrupt_out_endpoint) :
udev->descriptor.bMaxPacketSize0;
dev->interrupt_out_buffer =
kmalloc(write_buffer_size*dev->interrupt_out_endpoint_size, GFP_KERNEL);
- if (!dev->interrupt_out_buffer) {
- dev_err(&intf->dev, "Couldn't allocate interrupt_out_buffer\n");
+ if (!dev->interrupt_out_buffer)
goto error;
- }
dev->interrupt_out_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->interrupt_out_urb)
goto error;
--
2.9.3
--
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 17/44] usb: host: xhci-tegra: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/host/xhci-tegra.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 0f53ae0f464e6d..d39b37be71f01f 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -1033,7 +1033,6 @@ static int tegra_xusb_probe(struct platform_device *pdev)
tegra->phys = devm_kcalloc(&pdev->dev, tegra->num_phys,
sizeof(*tegra->phys), GFP_KERNEL);
if (!tegra->phys) {
- dev_err(&pdev->dev, "failed to allocate PHY array\n");
err = -ENOMEM;
goto put_padctl;
}
--
2.9.3
--
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 00/44] usb: don't print on ENOMEM
Here is my next series to save memory by removing unneeded strings. It removes in the usb subsystem all unspecific error messages after calling malloc-based functions, i.e. (devm_)k[zcm]alloc. kmalloc prints enough information in that case. If the message was specific (e.g. "can't save CLEAR_TT_BUFFER state"), I left it. This series saves ~4.5KB of "out of memory" permutations in .text and .rodata. For modified lines, (x == NULL) was replaced with (!NULL) as well. This seems to be the dominant style in this subsystem and checkpatch recommends it as well (and I prefer it, too). Wolfram Sang (44): usb: atm: cxacru: don't print on ENOMEM usb: atm: speedtch: don't print on ENOMEM usb: atm: ueagle-atm: don't print on ENOMEM usb: atm: usbatm: don't print on ENOMEM usb: class: usbtmc: don't print on ENOMEM usb: core: hcd: don't print on ENOMEM usb: core: hub: don't print on ENOMEM usb: core: message: don't print on ENOMEM usb: core: urb: don't print on ENOMEM usb: dwc2: gadget: don't print on ENOMEM usb: gadget: udc: fsl_qe_udc: don't print on ENOMEM usb: gadget: udc: goku_udc: don't print on ENOMEM usb: gadget: udc: udc-xilinx: don't print on ENOMEM usb: host: fhci-hcd: don't print on ENOMEM usb: host: max3421-hcd: don't print on ENOMEM usb: host: uhci-hcd: don't print on ENOMEM usb: host: xhci-tegra: don't print on ENOMEM usb: host: xhci: don't print on ENOMEM usb: misc: adutux: don't print on ENOMEM usb: misc: appledisplay: don't print on ENOMEM usb: misc: cypress_cy7c63: don't print on ENOMEM usb: misc: cytherm: don't print on ENOMEM usb: misc: ftdi-elan: don't print on ENOMEM usb: misc: idmouse: don't print on ENOMEM usb: misc: iowarrior: don't print on ENOMEM usb: misc: ldusb: don't print on ENOMEM usb: misc: legousbtower: don't print on ENOMEM usb: misc: lvstest: don't print on ENOMEM usb: misc: trancevibrator: don't print on ENOMEM usb: misc: usblcd: don't print on ENOMEM usb: misc: usbsevseg: don't print on ENOMEM usb: misc: uss720: don't print on ENOMEM usb: misc: yurex: don't print on ENOMEM usb: musb: am35x: don't print on ENOMEM usb: musb: da8xx: don't print on ENOMEM usb: renesas_usbhs: mod_gadget: don't print on ENOMEM usb: renesas_usbhs: mod_host: don't print on ENOMEM usb: renesas_usbhs: pipe: don't print on ENOMEM usb: storage: alauda: don't print on ENOMEM usb: storage: sddr09: don't print on ENOMEM usb: usb-skeleton: don't print on ENOMEM usb: wusbcore: crypto: don't print on ENOMEM usb: wusbcore: security: don't print on ENOMEM usb: wusbcore: wa-nep: don't print on ENOMEM drivers/usb/atm/cxacru.c | 4 +--- drivers/usb/atm/speedtch.c | 1 - drivers/usb/atm/ueagle-atm.c | 9 ++--- drivers/usb/atm/usbatm.c | 7 +-- drivers/usb/class/usbtmc.c | 4 +--- drivers/usb/core/hcd.c | 4 +--- drivers/usb/core/hub.c | 9 +++-- drivers/usb/core/message.c | 5 + drivers/usb/core/urb.c | 4 +--- drivers/usb/dwc2/gadget.c | 8 ++-- drivers/usb/gadget/udc/fsl_qe_udc.c| 16 drivers/usb/gadget/udc/goku_udc.c | 3 +-- drivers/usb/gadget/udc/udc-xilinx.c| 4 +--- drivers/usb/host/fhci-hcd.c| 4 +--- drivers/usb/host/max3421-hcd.c | 8 ++-- drivers/usb/host/uhci-hcd.c| 5 + drivers/usb/host/xhci-tegra.c | 1 - drivers/usb/host/xhci.c| 4 +--- drivers/usb/misc/adutux.c | 13 +++-- drivers/usb/misc/appledisplay.c| 3 --- drivers/usb/misc/cypress_cy7c63.c | 5 + drivers/usb/misc/cytherm.c | 32 drivers/usb/misc/ftdi-elan.c | 1 - drivers/usb/misc/idmouse.c | 1 - drivers/usb/misc/iowarrior.c | 20 ++-- drivers/usb/misc/ldusb.c | 20 +--- drivers/usb/misc/legousbtower.c| 16 drivers/usb/misc/lvstest.c | 4 +--- drivers/usb/misc/trancevibrator.c | 3 +-- drivers/usb/misc/usblcd.c | 9 ++--- drivers/usb/misc/usbsevseg.c | 8 ++-- drivers/usb/misc/uss720.c | 4 +--- drivers/usb/misc/yurex.c | 8 ++-- drivers/usb/musb/am35x.c | 4 +--- drivers/usb/musb/da8xx.c | 4 +--- drivers/usb/renesas_usbhs/mod_gadget.c | 6 +- drivers/usb/renesas_usbhs/mod_host.c | 10 ++ drivers/usb/renesas_usbhs/pipe.c | 4 +--- drivers/usb/storage/alauda.c | 11 +++ drivers/usb/storage/sddr09.c | 14 -- drivers/usb/usb-skeleton.c | 9 ++--- drivers/usb/wusbcore/crypto.c | 4 +--- drivers/usb/wusbcore/security.c| 4 +--- drivers/usb/wusbcore/wa-nep.c | 5 + 44 files changed, 78 insertions
[PATCH 29/44] usb: misc: trancevibrator: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/trancevibrator.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/misc/trancevibrator.c
b/drivers/usb/misc/trancevibrator.c
index 4145314a515b95..9795457723d86c 100644
--- a/drivers/usb/misc/trancevibrator.c
+++ b/drivers/usb/misc/trancevibrator.c
@@ -95,8 +95,7 @@ static int tv_probe(struct usb_interface *interface,
int retval;
dev = kzalloc(sizeof(struct trancevibrator), GFP_KERNEL);
- if (dev == NULL) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (!dev) {
retval = -ENOMEM;
goto error;
}
--
2.9.3
--
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 36/44] usb: renesas_usbhs: mod_gadget: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/renesas_usbhs/mod_gadget.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
b/drivers/usb/renesas_usbhs/mod_gadget.c
index 92bc83b92d10d3..8e326ac00c9fed 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -335,7 +335,6 @@ static void __usbhsg_recip_send_status(struct usbhsg_gpriv
*gpriv,
buf = kmalloc(sizeof(*buf), GFP_ATOMIC);
if (!buf) {
usb_ep_free_request(&dcp->ep, req);
- dev_err(dev, "recip data allocation fail\n");
return;
}
@@ -1062,14 +1061,11 @@ int usbhs_mod_gadget_probe(struct usbhs_priv *priv)
int ret;
gpriv = kzalloc(sizeof(struct usbhsg_gpriv), GFP_KERNEL);
- if (!gpriv) {
- dev_err(dev, "Could not allocate gadget priv\n");
+ if (!gpriv)
return -ENOMEM;
- }
uep = kzalloc(sizeof(struct usbhsg_uep) * pipe_size, GFP_KERNEL);
if (!uep) {
- dev_err(dev, "Could not allocate ep\n");
ret = -ENOMEM;
goto usbhs_mod_gadget_probe_err_gpriv;
}
--
2.9.3
--
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 41/44] usb: usb-skeleton: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/usb-skeleton.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/usb-skeleton.c b/drivers/usb/usb-skeleton.c
index 89e02a7529b785..5133a0792eb041 100644
--- a/drivers/usb/usb-skeleton.c
+++ b/drivers/usb/usb-skeleton.c
@@ -499,10 +499,8 @@ static int skel_probe(struct usb_interface *interface,
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
- if (!dev) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (!dev)
goto error;
- }
kref_init(&dev->kref);
sema_init(&dev->limit_sem, WRITES_IN_FLIGHT);
mutex_init(&dev->io_mutex);
@@ -526,11 +524,8 @@ static int skel_probe(struct usb_interface *interface,
dev->bulk_in_size = buffer_size;
dev->bulk_in_endpointAddr = endpoint->bEndpointAddress;
dev->bulk_in_buffer = kmalloc(buffer_size, GFP_KERNEL);
- if (!dev->bulk_in_buffer) {
- dev_err(&interface->dev,
- "Could not allocate bulk_in_buffer\n");
+ if (!dev->bulk_in_buffer)
goto error;
- }
dev->bulk_in_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->bulk_in_urb)
goto error;
--
2.9.3
--
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 18/44] usb: host: xhci: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/host/xhci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01d96c9b3a75b9..1a4ca02729c274 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -295,10 +295,8 @@ static int xhci_setup_msix(struct xhci_hcd *xhci)
xhci->msix_entries =
kmalloc((sizeof(struct msix_entry))*xhci->msix_count,
GFP_KERNEL);
- if (!xhci->msix_entries) {
- xhci_err(xhci, "Failed to allocate MSI-X entries\n");
+ if (!xhci->msix_entries)
return -ENOMEM;
- }
for (i = 0; i < xhci->msix_count; i++) {
xhci->msix_entries[i].entry = i;
--
2.9.3
--
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 05/44] usb: class: usbtmc: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/class/usbtmc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 22c235adacb3ad..da4f2509f56775 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -1476,10 +1476,8 @@ static int usbtmc_probe(struct usb_interface *intf,
/* allocate buffer for interrupt in */
data->iin_buffer = kmalloc(data->iin_wMaxPacketSize,
GFP_KERNEL);
- if (!data->iin_buffer) {
- dev_err(&intf->dev, "Failed to allocate int buf\n");
+ if (!data->iin_buffer)
goto error_register;
- }
/* fill interrupt urb */
usb_fill_int_urb(data->iin_urb, data->usb_dev,
--
2.9.3
--
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 25/44] usb: misc: iowarrior: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/iowarrior.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index 7defa34dd4fa8b..095778ff984de2 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -278,7 +278,7 @@ static ssize_t iowarrior_read(struct file *file, char
__user *buffer,
dev = file->private_data;
/* verify that the device wasn't unplugged */
- if (dev == NULL || !dev->present)
+ if (!dev || !dev->present)
return -ENODEV;
dev_dbg(&dev->interface->dev, "minor %d, count = %zd\n",
@@ -480,9 +480,8 @@ static long iowarrior_ioctl(struct file *file, unsigned int
cmd,
int io_res; /* checks for bytes read/written and
copy_to/from_user results */
dev = file->private_data;
- if (dev == NULL) {
+ if (!dev)
return -ENODEV;
- }
buffer = kzalloc(dev->report_size, GFP_KERNEL);
if (!buffer)
@@ -652,9 +651,8 @@ static int iowarrior_release(struct inode *inode, struct
file *file)
int retval = 0;
dev = file->private_data;
- if (dev == NULL) {
+ if (!dev)
return -ENODEV;
- }
dev_dbg(&dev->interface->dev, "minor %d\n", dev->minor);
@@ -764,10 +762,8 @@ static int iowarrior_probe(struct usb_interface *interface,
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(struct iowarrior), GFP_KERNEL);
- if (dev == NULL) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (!dev)
return retval;
- }
mutex_init(&dev->mutex);
@@ -813,10 +809,8 @@ static int iowarrior_probe(struct usb_interface *interface,
if (!dev->int_in_urb)
goto error;
dev->int_in_buffer = kmalloc(dev->report_size, GFP_KERNEL);
- if (!dev->int_in_buffer) {
- dev_err(&interface->dev, "Couldn't allocate int_in_buffer\n");
+ if (!dev->int_in_buffer)
goto error;
- }
usb_fill_int_urb(dev->int_in_urb, dev->udev,
usb_rcvintpipe(dev->udev,
dev->int_in_endpoint->bEndpointAddress),
@@ -827,10 +821,8 @@ static int iowarrior_probe(struct usb_interface *interface,
dev->read_queue =
kmalloc(((dev->report_size + 1) * MAX_INTERRUPT_BUFFER),
GFP_KERNEL);
- if (!dev->read_queue) {
- dev_err(&interface->dev, "Couldn't allocate read_queue\n");
+ if (!dev->read_queue)
goto error;
- }
/* Get the serial-number of the chip */
memset(dev->chip_serial, 0x00, sizeof(dev->chip_serial));
usb_string(udev, udev->descriptor.iSerialNumber, dev->chip_serial,
--
2.9.3
--
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 13/44] usb: gadget: udc: udc-xilinx: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/gadget/udc/udc-xilinx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-xilinx.c
b/drivers/usb/gadget/udc/udc-xilinx.c
index f8bf290f189444..588e2531b8b81e 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -973,10 +973,8 @@ static struct usb_request *xudc_ep_alloc_request(struct
usb_ep *_ep,
udc = ep->udc;
req = kzalloc(sizeof(*req), gfp_flags);
- if (!req) {
- dev_err(udc->dev, "%s:not enough memory", __func__);
+ if (!req)
return NULL;
- }
req->ep = ep;
INIT_LIST_HEAD(&req->queue);
--
2.9.3
--
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 38/44] usb: renesas_usbhs: pipe: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/renesas_usbhs/pipe.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/pipe.c b/drivers/usb/renesas_usbhs/pipe.c
index c238772b9e9e1a..9396a8c14af801 100644
--- a/drivers/usb/renesas_usbhs/pipe.c
+++ b/drivers/usb/renesas_usbhs/pipe.c
@@ -804,10 +804,8 @@ int usbhs_pipe_probe(struct usbhs_priv *priv)
}
info->pipe = kzalloc(sizeof(struct usbhs_pipe) * pipe_size, GFP_KERNEL);
- if (!info->pipe) {
- dev_err(dev, "Could not allocate pipe\n");
+ if (!info->pipe)
return -ENOMEM;
- }
info->size = pipe_size;
--
2.9.3
--
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 11/44] usb: gadget: udc: fsl_qe_udc: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/gadget/udc/fsl_qe_udc.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index cf8819a5c5b263..9d6b2c8eed4294 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -421,10 +421,8 @@ static int qe_ep_rxbd_update(struct qe_ep *ep)
bd = ep->rxbase;
ep->rxframe = kmalloc(sizeof(*ep->rxframe), GFP_ATOMIC);
- if (ep->rxframe == NULL) {
- dev_err(ep->udc->dev, "malloc rxframe failed\n");
+ if (!ep->rxframe)
return -ENOMEM;
- }
qe_frame_init(ep->rxframe);
@@ -435,9 +433,7 @@ static int qe_ep_rxbd_update(struct qe_ep *ep)
size = (ep->ep.maxpacket + USB_CRC_SIZE + 2) * (bdring_len + 1);
ep->rxbuffer = kzalloc(size, GFP_ATOMIC);
- if (ep->rxbuffer == NULL) {
- dev_err(ep->udc->dev, "malloc rxbuffer failed,size=%d\n",
- size);
+ if (!ep->rxbuffer) {
kfree(ep->rxframe);
return -ENOMEM;
}
@@ -668,10 +664,8 @@ static int qe_ep_init(struct qe_udc *udc,
if ((ep->tm == USBP_TM_CTL) || (ep->dir == USB_DIR_IN)) {
ep->txframe = kmalloc(sizeof(*ep->txframe), GFP_ATOMIC);
- if (ep->txframe == NULL) {
- dev_err(udc->dev, "malloc txframe failed\n");
+ if (!ep->txframe)
goto en_done2;
- }
qe_frame_init(ep->txframe);
}
@@ -2347,10 +2341,8 @@ static struct qe_udc *qe_udc_config(struct
platform_device *ofdev)
u32 offset;
udc = kzalloc(sizeof(*udc), GFP_KERNEL);
- if (udc == NULL) {
- dev_err(&ofdev->dev, "malloc udc failed\n");
+ if (!udc)
goto cleanup;
- }
udc->dev = &ofdev->dev;
--
2.9.3
--
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 43/44] usb: wusbcore: security: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/wusbcore/security.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/wusbcore/security.c b/drivers/usb/wusbcore/security.c
index b66faaf3e842e8..8c9421b69da00a 100644
--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -374,10 +374,8 @@ int wusb_dev_4way_handshake(struct wusbhc *wusbhc, struct
wusb_dev *wusb_dev,
struct wusb_keydvt_out keydvt_out;
hs = kcalloc(3, sizeof(hs[0]), GFP_KERNEL);
- if (hs == NULL) {
- dev_err(dev, "can't allocate handshake data\n");
+ if (!hs)
goto error_kzalloc;
- }
/* We need to turn encryption before beginning the 4way
* hshake (WUSB1.0[.3.2.2]) */
--
2.9.3
--
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 10/44] usb: dwc2: gadget: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/dwc2/gadget.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index af46adfae41ca5..2ff03ae08e144d 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3908,17 +3908,13 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
hsotg->ctrl_buff = devm_kzalloc(hsotg->dev,
DWC2_CTRL_BUFF_SIZE, GFP_KERNEL);
- if (!hsotg->ctrl_buff) {
- dev_err(dev, "failed to allocate ctrl request buff\n");
+ if (!hsotg->ctrl_buff)
return -ENOMEM;
- }
hsotg->ep0_buff = devm_kzalloc(hsotg->dev,
DWC2_CTRL_BUFF_SIZE, GFP_KERNEL);
- if (!hsotg->ep0_buff) {
- dev_err(dev, "failed to allocate ctrl reply buff\n");
+ if (!hsotg->ep0_buff)
return -ENOMEM;
- }
ret = devm_request_irq(hsotg->dev, irq, dwc2_hsotg_irq, IRQF_SHARED,
dev_name(hsotg->dev), hsotg);
--
2.9.3
--
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 02/44] usb: atm: speedtch: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/atm/speedtch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/atm/speedtch.c b/drivers/usb/atm/speedtch.c
index 0270d1312f834f..5083eb5b0d5ed9 100644
--- a/drivers/usb/atm/speedtch.c
+++ b/drivers/usb/atm/speedtch.c
@@ -817,7 +817,6 @@ static int speedtch_bind(struct usbatm_data *usbatm,
instance = kzalloc(sizeof(*instance), GFP_KERNEL);
if (!instance) {
- usb_err(usbatm, "%s: no memory for instance data!\n", __func__);
ret = -ENOMEM;
goto fail_release;
}
--
2.9.3
--
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 15/44] usb: host: max3421-hcd: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/host/max3421-hcd.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index 2f7690092a7ffb..369869a29ebd4d 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1856,15 +1856,11 @@ max3421_probe(struct spi_device *spi)
INIT_LIST_HEAD(&max3421_hcd->ep_list);
max3421_hcd->tx = kmalloc(sizeof(*max3421_hcd->tx), GFP_KERNEL);
- if (!max3421_hcd->tx) {
- dev_err(&spi->dev, "failed to kmalloc tx buffer\n");
+ if (!max3421_hcd->tx)
goto error;
- }
max3421_hcd->rx = kmalloc(sizeof(*max3421_hcd->rx), GFP_KERNEL);
- if (!max3421_hcd->rx) {
- dev_err(&spi->dev, "failed to kmalloc rx buffer\n");
+ if (!max3421_hcd->rx)
goto error;
- }
max3421_hcd->spi_thread = kthread_run(max3421_spi_thread, hcd,
"max3421_spi_thread");
--
2.9.3
--
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 31/44] usb: misc: usbsevseg: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/usbsevseg.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/misc/usbsevseg.c b/drivers/usb/misc/usbsevseg.c
index 1fe6b73c22f300..a0ba5298160c56 100644
--- a/drivers/usb/misc/usbsevseg.c
+++ b/drivers/usb/misc/usbsevseg.c
@@ -128,10 +128,8 @@ static void update_display_visual(struct usb_sevsegdev
*mydev, gfp_t mf)
return;
buffer = kzalloc(MAXLEN, mf);
- if (!buffer) {
- dev_err(&mydev->udev->dev, "out of memory\n");
+ if (!buffer)
return;
- }
/* The device is right to left, where as you write left to right */
for (i = 0; i < mydev->textlength; i++)
@@ -346,10 +344,8 @@ static int sevseg_probe(struct usb_interface *interface,
int rc = -ENOMEM;
mydev = kzalloc(sizeof(struct usb_sevsegdev), GFP_KERNEL);
- if (mydev == NULL) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (!mydev)
goto error_mem;
- }
mydev->udev = usb_get_dev(udev);
mydev->intf = interface;
--
2.9.3
--
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 03/44] usb: atm: ueagle-atm: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/atm/ueagle-atm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
index f198291630d7dd..df67815f74e680 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -2196,11 +2196,8 @@ static int uea_boot(struct uea_softc *sc)
load_XILINX_firmware(sc);
intr = kmalloc(size, GFP_KERNEL);
- if (!intr) {
- uea_err(INS_TO_USBDEV(sc),
- "cannot allocate interrupt package\n");
+ if (!intr)
goto err0;
- }
sc->urb_int = usb_alloc_urb(0, GFP_KERNEL);
if (!sc->urb_int)
@@ -2559,10 +2556,8 @@ static int uea_bind(struct usbatm_data *usbatm, struct
usb_interface *intf,
}
sc = kzalloc(sizeof(struct uea_softc), GFP_KERNEL);
- if (!sc) {
- uea_err(usb, "uea_init: not enough memory !\n");
+ if (!sc)
return -ENOMEM;
- }
sc->usb_dev = usb;
usbatm->driver_data = sc;
--
2.9.3
--
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 33/44] usb: misc: yurex: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/yurex.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c
index bb606bdc25e558..54e53ac4c08fd7 100644
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -200,10 +200,8 @@ static int yurex_probe(struct usb_interface *interface,
const struct usb_device_
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
- if (!dev) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (!dev)
goto error;
- }
kref_init(&dev->kref);
mutex_init(&dev->io_mutex);
spin_lock_init(&dev->lock);
@@ -236,10 +234,8 @@ static int yurex_probe(struct usb_interface *interface,
const struct usb_device_
/* allocate buffer for control req */
dev->cntl_req = kmalloc(YUREX_BUF_SIZE, GFP_KERNEL);
- if (!dev->cntl_req) {
- dev_err(&interface->dev, "Could not allocate cntl_req\n");
+ if (!dev->cntl_req)
goto error;
- }
/* allocate buffer for control msg */
dev->cntl_buffer = usb_alloc_coherent(dev->udev, YUREX_BUF_SIZE,
--
2.9.3
--
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 27/44] usb: misc: legousbtower: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/legousbtower.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/misc/legousbtower.c b/drivers/usb/misc/legousbtower.c
index 52b41fb66792eb..ece9b3c1eaac29 100644
--- a/drivers/usb/misc/legousbtower.c
+++ b/drivers/usb/misc/legousbtower.c
@@ -817,10 +817,8 @@ static int tower_probe (struct usb_interface *interface,
const struct usb_device
dev = kmalloc (sizeof(struct lego_usb_tower), GFP_KERNEL);
- if (dev == NULL) {
- dev_err(idev, "Out of memory\n");
+ if (!dev)
goto exit;
- }
mutex_init(&dev->lock);
@@ -871,23 +869,17 @@ static int tower_probe (struct usb_interface *interface,
const struct usb_device
}
dev->read_buffer = kmalloc (read_buffer_size, GFP_KERNEL);
- if (!dev->read_buffer) {
- dev_err(idev, "Couldn't allocate read_buffer\n");
+ if (!dev->read_buffer)
goto error;
- }
dev->interrupt_in_buffer = kmalloc
(usb_endpoint_maxp(dev->interrupt_in_endpoint), GFP_KERNEL);
- if (!dev->interrupt_in_buffer) {
- dev_err(idev, "Couldn't allocate interrupt_in_buffer\n");
+ if (!dev->interrupt_in_buffer)
goto error;
- }
dev->interrupt_in_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->interrupt_in_urb)
goto error;
dev->interrupt_out_buffer = kmalloc (write_buffer_size, GFP_KERNEL);
- if (!dev->interrupt_out_buffer) {
- dev_err(idev, "Couldn't allocate interrupt_out_buffer\n");
+ if (!dev->interrupt_out_buffer)
goto error;
- }
dev->interrupt_out_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->interrupt_out_urb)
goto error;
--
2.9.3
--
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 23/44] usb: misc: ftdi-elan: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/ftdi-elan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 45f303c1cc49ef..9beba9748d0f24 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -2733,7 +2733,6 @@ static int ftdi_elan_probe(struct usb_interface
*interface,
ftdi->bulk_in_endpointAddr = endpoint->bEndpointAddress;
ftdi->bulk_in_buffer = kmalloc(buffer_size, GFP_KERNEL);
if (!ftdi->bulk_in_buffer) {
- dev_err(&ftdi->udev->dev, "Could not allocate
bulk_in_buffer\n");
retval = -ENOMEM;
goto error;
}
--
2.9.3
--
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 39/44] usb: storage: alauda: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/storage/alauda.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c
index 1d8b03c8103053..878b4b8761f5a6 100644
--- a/drivers/usb/storage/alauda.c
+++ b/drivers/usb/storage/alauda.c
@@ -939,10 +939,8 @@ static int alauda_read_data(struct us_data *us, unsigned
long address,
len = min(sectors, blocksize) * (pagesize + 64);
buffer = kmalloc(len, GFP_NOIO);
- if (buffer == NULL) {
- printk(KERN_WARNING "alauda_read_data: Out of memory\n");
+ if (!buffer)
return USB_STOR_TRANSPORT_ERROR;
- }
/* Figure out the initial LBA and page */
lba = address >> blockshift;
@@ -1033,18 +1031,15 @@ static int alauda_write_data(struct us_data *us,
unsigned long address,
len = min(sectors, blocksize) * pagesize;
buffer = kmalloc(len, GFP_NOIO);
- if (buffer == NULL) {
- printk(KERN_WARNING "alauda_write_data: Out of memory\n");
+ if (!buffer)
return USB_STOR_TRANSPORT_ERROR;
- }
/*
* We also need a temporary block buffer, where we read in the old data,
* overwrite parts with the new data, and manipulate the redundancy data
*/
blockbuffer = kmalloc((pagesize + 64) * blocksize, GFP_NOIO);
- if (blockbuffer == NULL) {
- printk(KERN_WARNING "alauda_write_data: Out of memory\n");
+ if (!blockbuffer) {
kfree(buffer);
return USB_STOR_TRANSPORT_ERROR;
}
--
2.9.3
--
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 21/44] usb: misc: cypress_cy7c63: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/cypress_cy7c63.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/misc/cypress_cy7c63.c
b/drivers/usb/misc/cypress_cy7c63.c
index 402b94dd253159..5c93a888c40e56 100644
--- a/drivers/usb/misc/cypress_cy7c63.c
+++ b/drivers/usb/misc/cypress_cy7c63.c
@@ -79,7 +79,6 @@ static int vendor_command(struct cypress *dev, unsigned char
request,
/* allocate some memory for the i/o buffer*/
iobuf = kzalloc(CYPRESS_MAX_REQSIZE, GFP_KERNEL);
if (!iobuf) {
- dev_err(&dev->udev->dev, "Out of memory!\n");
retval = -ENOMEM;
goto error;
}
@@ -208,10 +207,8 @@ static int cypress_probe(struct usb_interface *interface,
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
- if (dev == NULL) {
- dev_err(&interface->dev, "Out of memory!\n");
+ if (!dev)
goto error_mem;
- }
dev->udev = usb_get_dev(interface_to_usbdev(interface));
--
2.9.3
--
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 08/44] usb: core: message: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/core/message.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 0406a59f05510c..5ab5c1a81462b6 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1760,17 +1760,14 @@ int usb_set_configuration(struct usb_device *dev, int
configuration)
nintf = cp->desc.bNumInterfaces;
new_interfaces = kmalloc(nintf * sizeof(*new_interfaces),
GFP_NOIO);
- if (!new_interfaces) {
- dev_err(&dev->dev, "Out of memory\n");
+ if (!new_interfaces)
return -ENOMEM;
- }
for (; n < nintf; ++n) {
new_interfaces[n] = kzalloc(
sizeof(struct usb_interface),
GFP_NOIO);
if (!new_interfaces[n]) {
- dev_err(&dev->dev, "Out of memory\n");
ret = -ENOMEM;
free_interfaces:
while (--n >= 0)
--
2.9.3
--
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 19/44] usb: misc: adutux: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/adutux.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c
index c34a0b6980cdcd..564268fca07a02 100644
--- a/drivers/usb/misc/adutux.c
+++ b/drivers/usb/misc/adutux.c
@@ -672,8 +672,7 @@ static int adu_probe(struct usb_interface *interface,
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(struct adu_device), GFP_KERNEL);
- if (dev == NULL) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (!dev) {
retval = -ENOMEM;
goto exit;
}
@@ -710,7 +709,6 @@ static int adu_probe(struct usb_interface *interface,
dev->read_buffer_primary = kmalloc((4 * in_end_size), GFP_KERNEL);
if (!dev->read_buffer_primary) {
- dev_err(&interface->dev, "Couldn't allocate
read_buffer_primary\n");
retval = -ENOMEM;
goto error;
}
@@ -723,7 +721,6 @@ static int adu_probe(struct usb_interface *interface,
dev->read_buffer_secondary = kmalloc((4 * in_end_size), GFP_KERNEL);
if (!dev->read_buffer_secondary) {
- dev_err(&interface->dev, "Couldn't allocate
read_buffer_secondary\n");
retval = -ENOMEM;
goto error;
}
@@ -735,10 +732,8 @@ static int adu_probe(struct usb_interface *interface,
memset(dev->read_buffer_secondary + (3 * in_end_size), 'h',
in_end_size);
dev->interrupt_in_buffer = kmalloc(in_end_size, GFP_KERNEL);
- if (!dev->interrupt_in_buffer) {
- dev_err(&interface->dev, "Couldn't allocate
interrupt_in_buffer\n");
+ if (!dev->interrupt_in_buffer)
goto error;
- }
/* debug code prime the buffer */
memset(dev->interrupt_in_buffer, 'i', in_end_size);
@@ -747,10 +742,8 @@ static int adu_probe(struct usb_interface *interface,
if (!dev->interrupt_in_urb)
goto error;
dev->interrupt_out_buffer = kmalloc(out_end_size, GFP_KERNEL);
- if (!dev->interrupt_out_buffer) {
- dev_err(&interface->dev, "Couldn't allocate
interrupt_out_buffer\n");
+ if (!dev->interrupt_out_buffer)
goto error;
- }
dev->interrupt_out_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->interrupt_out_urb)
goto error;
--
2.9.3
--
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 30/44] usb: misc: usblcd: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/misc/usblcd.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/misc/usblcd.c b/drivers/usb/misc/usblcd.c
index 1184390508e983..9f48419abc46b9 100644
--- a/drivers/usb/misc/usblcd.c
+++ b/drivers/usb/misc/usblcd.c
@@ -321,10 +321,8 @@ static int lcd_probe(struct usb_interface *interface,
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
- if (dev == NULL) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (!dev)
goto error;
- }
kref_init(&dev->kref);
sema_init(&dev->limit_sem, USB_LCD_CONCURRENT_WRITES);
init_usb_anchor(&dev->submitted);
@@ -351,11 +349,8 @@ static int lcd_probe(struct usb_interface *interface,
dev->bulk_in_size = buffer_size;
dev->bulk_in_endpointAddr = endpoint->bEndpointAddress;
dev->bulk_in_buffer = kmalloc(buffer_size, GFP_KERNEL);
- if (!dev->bulk_in_buffer) {
- dev_err(&interface->dev,
- "Could not allocate bulk_in_buffer\n");
+ if (!dev->bulk_in_buffer)
goto error;
- }
}
if (!dev->bulk_out_endpointAddr &&
--
2.9.3
--
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 35/44] usb: musb: da8xx: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/musb/da8xx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index b03d3b867fca2f..3c4dd1658f28db 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -494,10 +494,8 @@ static int da8xx_probe(struct platform_device *pdev)
int ret = -ENOMEM;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
- if (!glue) {
- dev_err(&pdev->dev, "failed to allocate glue context\n");
+ if (!glue)
goto err0;
- }
clk = clk_get(&pdev->dev, "usb20");
if (IS_ERR(clk)) {
--
2.9.3
--
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 06/44] usb: core: hcd: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/core/hcd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index d2e3f655c26f6c..a0c87b617eddea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2517,10 +2517,8 @@ struct usb_hcd *usb_create_shared_hcd(const struct
hc_driver *driver,
struct usb_hcd *hcd;
hcd = kzalloc(sizeof(*hcd) + driver->hcd_priv_size, GFP_KERNEL);
- if (!hcd) {
- dev_dbg (dev, "hcd alloc failed\n");
+ if (!hcd)
return NULL;
- }
if (primary_hcd == NULL) {
hcd->address0_mutex = kmalloc(sizeof(*hcd->address0_mutex),
GFP_KERNEL);
--
2.9.3
--
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 07/44] usb: core: hub: don't print on ENOMEM
All kmalloc-based functions print enough information on failures.
Signed-off-by: Wolfram Sang
---
drivers/usb/core/hub.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1d5fc32d06d007..b48dc76385b652 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1823,10 +1823,8 @@ descriptor_error:
dev_info(&intf->dev, "USB hub found\n");
hub = kzalloc(sizeof(*hub), GFP_KERNEL);
- if (!hub) {
- dev_dbg(&intf->dev, "couldn't kmalloc hub struct\n");
+ if (!hub)
return -ENOMEM;
- }
kref_init(&hub->kref);
hub->intfdev = &intf->dev;
@@ -5337,11 +5335,10 @@ static int descriptors_changed(struct usb_device *udev,
}
buf = kmalloc(len, GFP_NOIO);
- if (buf == NULL) {
- dev_err(&udev->dev, "no mem to re-read configs after reset\n");
+ if (!buf)
/* assume the worst */
return 1;
- }
+
for (index = 0; index < udev->descriptor.bNumConfigurations; index++) {
old_length = le16_to_cpu(udev->config[index].desc.wTotalLength);
length = usb_get_descriptor(udev, USB_DT_CONFIG, index, buf,
--
2.9.3
--
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: xHCI problem? [was Re: Erratic USB device behavior and device loss]
Ulf: Ritesh has collected logs showing that his Realtek RTS5129 USB card reader (drivers/mfd/rtsx_usb.c, drivers/mmc/host/rtsx_usb_sdmmc.c) goes into runtime autosuspend every 3 seconds and then immediately resumes. This sounds like something is failing to call pm_runtime_mark_last_busy(). He's using a 4.7 kernel. In addition, the device gets disconnected from the USB bus from time to time. This appears to be a completely separate issue. For now, I'd like to fix the runtime PM problem. But I don't know anything about the mmc core, so perhaps you can help. On Thu, 25 Aug 2016, Ritesh Raj Sarraf wrote: > > Do you happen to know which driver is being used: the memstick > > (rtsx_usb_ms) or mmc (rtsx_usb_sdmmc) driver? I suppose this may > > depend on what type of card you insert in the reader. > > > > > I think it is the rtsx_usb_sdmmc which is in use. I removed the rtsx_usb_ms > kernel module and still was able to access the sdcard. > > rrs@learner:~$ lsmod | grep usb_ms > 2016-08-25 / 18:45:52 ♒♒♒ ☹ => 1 > > rrs@learner:~$ lsmod | grep usb_sd > rtsx_usb_sdmmc 24576 0 > rtsx_usb 24576 1 rtsx_usb_sdmmc > mmc_core 135168 4 mmc_block,sdhci,sdhci_acpi,rtsx_usb_sdmmc > 2016-08-25 / 18:45:55 ♒♒♒ ☺ > > > The interesting bit is that when I enter the adapter into the reader, I get > the > following error 5 times, and then it can access the card. > > [ 496.822613] mmc0: tuning execution failed: -22 > [ 496.822629] mmc0: error -22 whilst initialising SD card > [ 501.980908] mmc0: tuning execution failed: -22 > [ 501.980922] mmc0: error -22 whilst initialising SD card > [ 507.119953] mmc0: tuning execution failed: -22 > [ 507.119968] mmc0: error -22 whilst initialising SD card > [ 513.148143] mmc0: tuning execution failed: -22 > [ 513.148157] mmc0: error -22 whilst initialising SD card > [ 518.702215] mmc0: tuning execution failed: -22 > [ 518.70] mmc0: error -22 whilst initialising SD card > [ 524.081122] mmc0: new ultra high speed SDR50 SDHC card at address 0002 > [ 524.082596] mmcblk0: mmc0:0002 NCard 14.9 GiB > [ 524.084240] mmcblk0: p1 > [ 524.306434] FAT-fs (mmcblk0p1): utf8 is not a recommended IO charset for > FAT > filesystems, filesystem will be case sensitive! I can't tell why those errors occur. It would require more debugging. At least they don't seem to cause any serious problems. > With your patch applied, the initial errors messages (xhci_hcd :00:14.0: > dev > 4 ep1out scatterlist error -104/-110) are not seen so far. This is because those errors occur when the device goes into runtime autosuspend and the computer tries to communicate with it while it is suspended. Both things (the autosuspend and the communication attempt) are bugs in the drivers. > The device does reset (as you had mentioned), but it doesn't seem to have any > power drain related negative effects. > > > rrs@learner:~$ less /var/tmp/dmesg-post-patch.txt | tail -n 25 > [11922.283067] wlan0: RX AssocResp from 00:40:77:bb:55:12 (capab=0x411 > status=0 > aid=1) > [11922.283743] wlan0: associated > [11922.283801] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > [11922.883849] systemd[1]: apt-daily.timer: Adding 8h 36min 18.323966s random > time. > [11923.081426] systemd[1]: apt-daily.timer: Adding 2h 23min 22.221062s random > time. > [13799.616838] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe > on > isa0060/serio0). > [13799.616843] atkbd serio0: Use 'setkeycodes e03e ' to make it > known. > [13799.625901] atkbd serio0: Unknown key released (translated set 2, code 0xbe > on isa0060/serio0). > [13799.625905] atkbd serio0: Use 'setkeycodes e03e ' to make it > known. > [13800.547966] usb 1-4: USB disconnect, device number 15 Spontaneous disconnect followed by reconnect a little later... > [13801.707137] usb 1-4: new high-speed USB device number 16 using xhci_hcd > [13801.880788] usb 1-4: New USB device found, idVendor=0bda, idProduct=0129 > [13801.880791] usb 1-4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [13801.880792] usb 1-4: Product: USB2.0-CRW > [13801.880793] usb 1-4: Manufacturer: Generic > [13801.880794] usb 1-4: SerialNumber: 2010020139600 > [13802.809031] usb 1-4: USB disconnect, device number 16 > [13803.390459] usb 1-4: new high-speed USB device number 18 using xhci_hcd > [13808.807084] usb 1-4: new high-speed USB device number 19 using xhci_hcd > [13808.980827] usb 1-4: New USB device found, idVendor=0bda, idProduct=0129 > [13808.980831] usb 1-4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [13808.980833] usb 1-4: Product: USB2.0-CRW > [13808.980834] usb 1-4: Manufacturer: Generic > [13808.980835] usb 1-4: SerialNumber: 2010020139600 > [14367.255033] usb 1-7: reset full-speed USB device number 5 using xhci_hcd > 2016-08-25 / 18:53:16 ♒♒♒ ☺ > > Note: These resets are seen without any card/adapter in the reader. The computer probably still wants
Re: [PATCH v2 7/7] musb: sunxi: Add support for platform_set_mode
Hi, On 22-08-16 18:10, Bin Liu wrote: On Mon, Aug 22, 2016 at 05:55:50PM +0200, Hans de Goede wrote: Hi, On 22-08-16 17:38, Bin Liu wrote: On Mon, Aug 22, 2016 at 05:32:57PM +0200, Hans de Goede wrote: When switching from host to peripheral mode, if an usb device is still plugged and enumerated, how do you handle the device disconnect? The phy code will report vbus low for long enough for the musb to end the current session. It already does this for boards which do not have working vbus detection. But you didn't disconnect DP/DM, right? then musb detects vbus is gone without receiving disconnect event, this is vbus error case, not a normal teardown. Correct, there is no way to disconnect DP/DM and reporting Vbus low for a while does the trick. Without physically disconnecting DP/DM, we still have a way to properly teardown the enumerated devices. Please check musb_softconnect_write() in musb_debugfs.c. That is manipulating the session bit in the devctl reg, that does not work to switch from device to host role or from host to device role, at least not on allwinner's musb implementation. I've already tried that before writing the code to report VBus low. I would think you have to call musb_root_disconnect() first to notify the core to teardown the enumerated devices. I tried that it does not help. It only affects the software state, the hardware will still stay in host-mode if it does not see vbus low for long enough). I didn't mean to use musb_root_disconnect() to replace your implementation. I suggest to add this call before lowing vbus to let the core tearing down the numerated devices. Note this is on devices which lack vbus detection (again this is simply physically not available on the PCB, just like some PCB's miss the id-pin). Normally this never is an issue, because when a host cable gets unplugged from a AB connector we see the id pin go high, disable the boards driving of Vbus and then the phy's Vbus detect will report low to the musb controller. In this case, DP/DM get disconnected before vbus line, so musb_root_disconnect() gets called in handling the disconnect interrupt event. I think it is better simulate this in your usecase, which does not generate disconnect event. Ah right, I ran some tests and indeed the hcd does not see a disconnect on role-change unless musb_root_disconnect() gets called, I'll send a v4 fixing this. Thank you for catching this. Regards, Hans Regards, -Bin. Anyways this is a solved problem, the reporting of Vbus low has been working fine for both boards which lack vbus-detection as well as for role-changing from sysfs. Regards, Hans -- 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 v4 7/7] musb: sunxi: Add support for platform_set_mode
This allows run-time dr_mode switching support via the "mode" musb
sysfs attribute.
Signed-off-by: Hans de Goede
---
Changes in v2:
-No changes
Changes in v3:
-Fix switch-case code style
Changes in v4:
-Call musb_root_disconnect() before role change to make sure any attached
devices get seen as disconnected by the kernel
---
drivers/usb/musb/sunxi.c | 61
1 file changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index c6ee166..1408245 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -74,6 +74,7 @@
#define SUNXI_MUSB_FL_HAS_SRAM 5
#define SUNXI_MUSB_FL_HAS_RESET6
#define SUNXI_MUSB_FL_NO_CONFIGDATA7
+#define SUNXI_MUSB_FL_PHY_MODE_PEND8
/* Our read/write methods need access and do not get passed in a musb ref :| */
static struct musb *sunxi_musb;
@@ -87,6 +88,7 @@ struct sunxi_glue {
struct phy *phy;
struct platform_device *usb_phy;
struct usb_phy *xceiv;
+ enum phy_mode phy_mode;
unsigned long flags;
struct work_struct work;
struct extcon_dev *extcon;
@@ -140,6 +142,9 @@ static void sunxi_musb_work(struct work_struct *work)
clear_bit(SUNXI_MUSB_FL_PHY_ON, &glue->flags);
}
}
+
+ if (test_and_clear_bit(SUNXI_MUSB_FL_PHY_MODE_PEND, &glue->flags))
+ phy_set_mode(glue->phy, glue->phy_mode);
}
static void sunxi_musb_set_vbus(struct musb *musb, int is_on)
@@ -341,6 +346,50 @@ static void sunxi_musb_dma_controller_destroy(struct
dma_controller *c)
{
}
+static int sunxi_musb_set_mode(struct musb *musb, u8 mode)
+{
+ struct sunxi_glue *glue = dev_get_drvdata(musb->controller->parent);
+ enum phy_mode new_mode;
+
+ switch (mode) {
+ case MUSB_HOST:
+ new_mode = PHY_MODE_USB_HOST;
+ break;
+ case MUSB_PERIPHERAL:
+ new_mode = PHY_MODE_USB_DEVICE;
+ break;
+ case MUSB_OTG:
+ new_mode = PHY_MODE_USB_OTG;
+ break;
+ default:
+ dev_err(musb->controller->parent,
+ "Error requested mode not supported by this kernel\n");
+ return -EINVAL;
+ }
+
+ if (glue->phy_mode == new_mode)
+ return 0;
+
+ if (musb->port_mode != MUSB_PORT_MODE_DUAL_ROLE) {
+ dev_err(musb->controller->parent,
+ "Error changing modes is only supported in dual role
mode\n");
+ return -EINVAL;
+ }
+
+ if (musb->port1_status & USB_PORT_STAT_ENABLE)
+ musb_root_disconnect(musb);
+
+ /*
+* phy_set_mode may sleep, and we're called with a spinlock held,
+* so let sunxi_musb_work deal with it.
+*/
+ glue->phy_mode = new_mode;
+ set_bit(SUNXI_MUSB_FL_PHY_MODE_PEND, &glue->flags);
+ schedule_work(&glue->work);
+
+ return 0;
+}
+
/*
* sunxi musb register layout
* 0x00 - 0x17 fifo regs, 1 long per fifo
@@ -568,6 +617,7 @@ static const struct musb_platform_ops sunxi_musb_ops = {
.writew = sunxi_musb_writew,
.dma_init = sunxi_musb_dma_controller_create,
.dma_exit = sunxi_musb_dma_controller_destroy,
+ .set_mode = sunxi_musb_set_mode,
.set_vbus = sunxi_musb_set_vbus,
.pre_root_reset_end = sunxi_musb_pre_root_reset_end,
.post_root_reset_end = sunxi_musb_post_root_reset_end,
@@ -614,21 +664,28 @@ static int sunxi_musb_probe(struct platform_device *pdev)
return -EINVAL;
}
+ glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
+ if (!glue)
+ return -ENOMEM;
+
memset(&pdata, 0, sizeof(pdata));
switch (usb_get_dr_mode(&pdev->dev)) {
#if defined CONFIG_USB_MUSB_DUAL_ROLE || defined CONFIG_USB_MUSB_HOST
case USB_DR_MODE_HOST:
pdata.mode = MUSB_PORT_MODE_HOST;
+ glue->phy_mode = PHY_MODE_USB_HOST;
break;
#endif
#if defined CONFIG_USB_MUSB_DUAL_ROLE || defined CONFIG_USB_MUSB_GADGET
case USB_DR_MODE_PERIPHERAL:
pdata.mode = MUSB_PORT_MODE_GADGET;
+ glue->phy_mode = PHY_MODE_USB_DEVICE;
break;
#endif
#ifdef CONFIG_USB_MUSB_DUAL_ROLE
case USB_DR_MODE_OTG:
pdata.mode = MUSB_PORT_MODE_DUAL_ROLE;
+ glue->phy_mode = PHY_MODE_USB_OTG;
break;
#endif
default:
@@ -638,10 +695,6 @@ static int sunxi_musb_probe(struct platform_device *pdev)
pdata.platform_ops = &sunxi_musb_ops;
pdata.config= &sunxi_musb_hdrc_config;
- glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
- if (!glue)
-
Re: [PATCH v3] usb: dwc3: gadget: add remaining sg entries to ring
On 8/25/2016 2:20 AM, Felipe Balbi wrote:
> Upon transfer completion after a full ring, let's
> add more TRBs to our ring in order to complete our
> request successfully.
>
> Signed-off-by: Felipe Balbi
> ---
>
> Changes since v1:
> - none
>
> Changes since v2:
> - fix regression found by John Youn
>
> drivers/usb/dwc3/gadget.c | 33 -
> 1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 90b3d7965136..c18bf1caad54 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -888,14 +888,13 @@ static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep)
> static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
> struct dwc3_request *req, unsigned int trbs_left)
> {
> - struct usb_request *request = &req->request;
> - struct scatterlist *sg = request->sg;
> + struct scatterlist *sg = req->sg;
> struct scatterlist *s;
> unsigned intlength;
> dma_addr_t dma;
> int i;
>
> - for_each_sg(sg, s, request->num_mapped_sgs, i) {
> + for_each_sg(sg, s, req->num_pending_sgs, i) {
> unsigned chain = true;
>
> length = sg_dma_len(s);
> @@ -945,7 +944,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep)
> return;
>
> list_for_each_entry_safe(req, n, &dep->pending_list, list) {
> - if (req->request.num_mapped_sgs > 0)
> + if (req->num_pending_sgs > 0)
> dwc3_prepare_one_trb_sg(dep, req, trbs_left--);
> else
> dwc3_prepare_one_trb_linear(dep, req, trbs_left--);
> @@ -1071,6 +1070,9 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
> struct dwc3_request *req)
> if (ret)
> return ret;
>
> + req->sg = req->request.sg;
> + req->num_pending_sgs= req->request.num_mapped_sgs;
> +
> list_add_tail(&req->list, &dep->pending_list);
>
> if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
> @@ -1935,22 +1937,30 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
> struct dwc3_ep *dep,
> int ret;
>
> list_for_each_entry_safe(req, n, &dep->started_list, list) {
> -
> + unsigned length;
> + unsigned actual;
> int chain;
>
> - chain = req->request.num_mapped_sgs > 0;
> + length = req->request.length;
> + chain = req->num_pending_sgs > 0;
> if (chain) {
> - struct scatterlist *sg = req->request.sg;
> + struct scatterlist *sg = req->sg;
> struct scatterlist *s;
> + unsigned int pending = req->num_pending_sgs;
> unsigned int i;
>
> - for_each_sg(sg, s, req->request.num_mapped_sgs, i) {
> + for_each_sg(sg, s, pending, i) {
> trb = &dep->trb_pool[dep->trb_dequeue];
> count += trb->size & DWC3_TRB_SIZE_MASK;
> dwc3_ep_inc_deq(dep);
>
> + req->sg = sg_next(s);
> + req->num_pending_sgs--;
> +
> ret = __dwc3_cleanup_done_trbs(dwc, dep, req,
> trb,
> event, status, chain);
> + if (ret)
> + break;
> }
> } else {
> trb = &dep->trb_pool[dep->trb_dequeue];
> @@ -1968,7 +1978,12 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
> struct dwc3_ep *dep,
>* should receive and we simply bounce the request back to the
>* gadget driver for further processing.
>*/
> - req->request.actual += req->request.length - count;
> + actual = length - req->request.actual;
> + req->request.actual = actual;
> +
> + if (ret && chain && (actual < length) && req->num_pending_sgs)
> + return __dwc3_gadget_kick_transfer(dep, 0);
> +
> dwc3_gadget_giveback(dep, req, status);
>
> if (ret)
>
Seems to work fine now on testing/next
Thanks,
John
--
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: [RESEND PATCH 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform
On 8/24/2016 1:54 AM, Randy Li wrote:
>
>
> On 08/24/2016 04:46 AM, John Youn wrote:
>> On 8/21/2016 12:32 PM, Randy Li wrote:
>>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>>> port) the PHY can get into a bad state when a wakeup is asserted (not
>>> just a wakeup from full system suspend but also a wakeup from
>>> autosuspend).
>>>
>>> We can get the PHY out of its bad state by asserting its "port reset",
>>> but unfortunately that seems to assert a reset onto the USB bus so it
>>> could confuse things if we don't actually deenumerate / reenumerate the
>>> device.
>>>
>>> We can also get the PHY out of its bad state by fully resetting it using
>>> the reset from the CRU (clock reset unit) in chip, which does a more full
>>> reset. The CRU-based reset appears to actually cause devices on the bus
>>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>>> way).
>>>
>>> It's unfortunate that we need to do a full re-enumeration of devices at
>>> wakeup time, but this is better than alternative of letting the bus get
>>> wedged.
>>>
>>> Signed-off-by: Randy Li
>>> ---
>>> drivers/usb/dwc2/core_intr.c | 11 +++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>>> index d85c5c9..f57c48a 100644
>>> --- a/drivers/usb/dwc2/core_intr.c
>>> +++ b/drivers/usb/dwc2/core_intr.c
>>> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct
>>> dwc2_hsotg *hsotg)
>>> static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>> {
>>> int ret;
>>> + struct device_node *np = hsotg->dev->of_node;
>>>
>>> /* Clear interrupt */
>>> dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
>>> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct
>>> dwc2_hsotg *hsotg)
>>> /* Restart the Phy Clock */
>>> pcgcctl &= ~PCGCTL_STOPPCLK;
>>> dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
>>> +
>>> + /*
>>> +* It is a quirk in Rockchip RK3288, causing by
>>> +* a hardware bug. This will propagate out and
>>> +* eventually we'll re-enumerate the device.
>>> +* Not great but the best we can do
>>
>> Remove the trailing whitespaces in this comment.
>>
>> Run scripts/checkpatch.pl to catch these.
> I see.
>>
>>> +*/
>>> + if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
>>> + hsotg->phy->ops->reset(hsotg->phy);
>>> +
>>
>> You should probably check for NULL before calling the reset()
>> callback.
> Sure.
>>
>> Also, I'd rather see a generic quirk property that you set for your
>> platform.
>>
>> Something like "phy_reset_on_wakeup_quirk".
> But Rob Herring want me to implied by the SoC specific compatible
> string. I agree with him. It is certainly bug in RK3288 platform.
> It is no found no the other platform.
Ok, I missed that before.
Based on the drivers I'm familiar with (like dwc3), you would typically add a
"quirk" anyways.
Felipe,
Do you have some policy or preference on this?
Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/6] usb: dwc3: gadget: add remaining sg entries to ring
On 8/25/2016 12:45 AM, Felipe Balbi wrote: > > Hi, > > Felipe Balbi writes: >>> On your testing/next, I see considerable slow down and file >>> corruption in mass storage. >>> >>> After bisecting, this patch seems to be the first one that shows >>> problems. The device fails even enumeration here. >>> >>> I haven't looked in detail at the changes but, do you have any ideas? >>> >>> I have attached driver logs. >> >> g_mass_storage doesn't use sglists, so I find this to be unlikely. I'll >> test again but I didn't notice any problems on my side. > > Few things: > > Host sent you a few Resets which I don't know why they're there: > > irq/16-dwc3-2849 [002] d..245.257835: dwc3_event: event (0101): > Reset [U0] > > [...] > > irq/16-dwc3-2849 [002] d..245.352847: dwc3_event: event (0101): > Reset [U0] > > [...] > > irq/16-dwc3-2849 [002] d..245.257835: dwc3_event: event (0101): > Reset [U0] > > [...] > > 4 requests per endpoint, why so few? To test throughput, I've been using > 96 requests per endpoint :-p Any trick to get it to do that? We haven't really used the g_mass_storage for performance testing yet. Regards, John -- 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 RFC V3.5] leds: trigger: Introduce an USB port trigger
On 08/25/2016 04:30 PM, Alan Stern wrote: On Thu, 25 Aug 2016, Jacek Anaszewski wrote: I'd see it as follows: #cat available_ports #1-1 1-2 2-1 #echo "1-1" > new_port #cat observed_ports #1-1 #echo "2-1" > new_port #cat observed_ports #1-1 2-1 We've already had few discussions about the sysfs designs trying to break the one-value-per-file rule for LED class device, and there was always strong resistance against. This scheme has multiple values in both the available_ports and observed_ports files. :-( Not that I have any better suggestions... Right, I forgot to add a note here, that this follows space separated list pattern similarly as in case of triggers attribute. Of course other suggestions are welcome. Also a description of the device connected to the port would be a nice feature, however I am not certain about the feasibility thereof. What kind of description do you mean? Where should it be used / where should it appear? Product name/symbol. Actually it should be USB subsystem responsibility to provide the means for querying the product name by port id, if it is possible at all. cat /sys/bus/usb/devices/PORT/product cat /sys/bus/usb/devices/PORT/manufacturer These will work if there is a device registered under PORT. I've found only idProduct and idVendor files. They indeed uniquely identify the device, but the numbers are not human readable. Is there a way to retrieve the corresponding names in kernel? Does the lsusb command do the mapping in the user space or maybe it takes the names from kernel? -- Best regards, Jacek Anaszewski -- 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] leds: trigger: Introduce an USB port trigger
Greg KH writes: > On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote: >> >> Good question. I would like to extend this USB port trigger in the >> future by reacting to USB activity. This involves playing with URBs >> and I believe that at that point it'd be getting too much USB specific >> to /rule them all/. > > Oh that's never going to work, sorry. USB "activity" happens deep in > USB host controller hardware, not up at the kernel level at all. It's > just too fast, and would take up too much CPU to do it otherwise. Heck, > even old UHCI 1.1 USB controllers did this. > > USB "activity" happens all the time, look at a USB bus analyzer if you > want to see what goes on. Teasing out what is "real data" and what is > just "normal bus activity" is impossible at the kernel level, OK, I am going to play stupid again: Does this mean that usbmon is impossible? > and really > makes no sense at all (your led would just be "on" all the time.) I don't see how this is any different from e.g. the network activity triggers. FWIW, on my system "cat /sys/kernel/debug/usb/usbmon/0u" can be silent for long periods, and show a rush of lines whenever there is USB activity. I imagine that a LED triggered by a hook in a similar place would be useful on systems with LEDs for that sort of stuff. Bjørn -- 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: [RFT PATCH v2 3/4] usb: dwc2: Properly account for the force mode delays
On 8/25/2016 3:01 AM, Heiko Stübner wrote:
> Hi John,
>
> Am Mittwoch, 24. August 2016, 16:20:01 schrieb John Youn:
>> When a force mode bit is set and the IDDIG debounce filter is enabled,
>> there is a delay for the forced mode to take effect. This delay is due
>> to the IDDIG debounce filter and is variable depending on the platform's
>> PHY clock speed. To account for this delay we can poll for the expected
>> mode.
>>
>> On a clear force mode, since we don't know what mode to poll for, delay
>> for a fixed 50 ms. This is the maximum delay based on the slowest PHY
>> clock speed.
>>
>> Signed-off-by: John Youn
>
> starting with this patch, I see debounce-failed messages:
> [7.934100] usb usb2-port1: connect-debounce failed
>
> on my rk3188. Port is in host-mode and I'll try to investigate further.
>
> One more thing below.
>
>> ---
>> drivers/usb/dwc2/core.c | 32 ++--
>> 1 file changed, 14 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>> index bb903e2..caad6121 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -397,9 +397,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>> * Checks are done in this function to determine whether doing a force
>> * would be valid or not.
>> *
>> - * If a force is done, it requires a 25ms delay to take effect.
>> - *
>> - * Returns true if the mode was forced.
>> + * If a force is done, it requires a IDDIG debounce filter delay if
>> + * the filter is configured and enabled. We poll the current mode of
>> + * the controller to account for this delay.
>> */
>> static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>> {
>> @@ -434,12 +434,17 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg,
>> bool host) gusbcfg |= set;
>> dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
>>
>> -msleep(25);
>> -return true;
>> +dwc2_wait_for_mode(hsotg, host, 50);
>
> missing a return value and thus resulting in
>
> ../drivers/usb/dwc2/core.c: In function ‘dwc2_force_mode’:
> ../drivers/usb/dwc2/core.c:438:1: warning: control reaches end of non-void
> function [-Wreturn-type]
>
Ok, I'll resubmit the series with this fix and without patch 4 for
now.
Thanks for testing.
I'm not sure what could be going on here and how it could affect the
hub port debounce. This patch doesn't really do much and only adjust a
few delays per the databook.
With the fixed series, could you provide a log with debug enabled in
the usb core and verbose debug enabled in dwc2? And also with/without
patch 3 applied?
In particular I'd like to know what delays are being introduced or
removed, and if the rk3188 has the IDDIG filter.
Regards,
John
--
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
