>
> Yes, ID interrupt (IDIE) is set.
>
> I noticed this backtrace in the kernel bootlog, but this only happens if
> the
> dr_mode="otg" , it comes from the host-mode irq handler :
>
> [2.757563] irq 238: nobody cared (try booting with the "irqpoll"
> option)
> [2.764398] CPU: 0 PID: 1
From: Hayes Wang
Date: Fri, 12 Jul 2013 16:26:16 +0800
>>> drivers/net/usb/r815x.c:38:16: sparse: cast to restricted __le32
>>> drivers/net/usb/r815x.c:67:15: sparse: cast to restricted __le32
>>> drivers/net/usb/r815x.c:69:13: sparse: incorrect type in assignment
>>> (different base types)
>
From: Hayes Wang
Date: Fri, 12 Jul 2013 16:26:15 +0800
> config: make ARCH=avr32 allyesconfig
> drivers/net/usb/r8152.c: In function 'rtl8152_start_xmit':
> drivers/net/usb/r8152.c:956: warning: integer overflow in expression
>
>955memset(tx_desc, 0, sizeof(*tx_desc));
> > 956
Hello.
On 07/11/2013 11:25 AM, Geert Uytterhoeven wrote:
When builtin (CONFIG_USB_FOTG210_UDC=y):
LD drivers/usb/gadget/built-in.o
WARNING: drivers/usb/gadget/built-in.o(.data+0xbf8): Section mismatch in
reference from the variable fotg210_driver to the function
.init.text:fotg210_u
On Fri, 12 Jul 2013, Kumar, Sanjay wrote:
> Hello Alan,
>
> Here is the sample device ID from HP Deskjet 2000 J210 series printer.
>
> MFG:HP;MDL:Deskjet 2000 J210
> series;CMD:PCL,DW-PCL,DESKJET,DYN;CLS:PRINTER;DES:CH390A;CID:HPIJVIPAV1;LEDMDIS:USB#07#01#02,USB#FF#04#01;SN:CN03N1C06M05HY;S:038
Hi Mathieu,
On Fri, Jul 12, 2013 at 01:08:28PM -0400, Mathieu Desnoyers wrote:
> * Sarah Sharp (sarah.a.sh...@linux.intel.com) wrote:
> > Thanks for the suggestion. I'm not familiar with all the userspace
> > tools for trace events, so I didn't know about the command parser. Is
> > there documen
Hello Alan,
Here is the sample device ID from HP Deskjet 2000 J210 series printer.
MFG:HP;MDL:Deskjet 2000 J210
series;CMD:PCL,DW-PCL,DESKJET,DYN;CLS:PRINTER;DES:CH390A;CID:HPIJVIPAV1;LEDMDIS:USB#07#01#02,USB#FF#04#01;SN:CN03N1C06M05HY;S:038000C484001021002c1f0001ec2880032;J:
Sarah Sharp writes:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
>
>> Instead of individual trace points for command I would recommend to
>> consider just pushing the whole command buffer to the trace point and
>> parse the command in trace-cmd plugin in user space. Kernel code w
On Fri, 12 Jul 2013, Hans de Goede wrote:
> > Are there any security implications to allowing any user on the system
> > to send a get_device_id request to a printer while it is in the middle
> > of a print job?
>
> To the best of my (limited) knowledge, no. As you indicated in the thread
> about
Hi,
On 07/12/2013 04:50 PM, Alan Stern wrote:
On Fri, 12 Jul 2013, Hans de Goede wrote:
For certain (HP) printers the printer device_id does not only contain a
static part identifying the printer, but it also contains a dynamic part
giving printer status, ink level, etc.
To get to this info v
* Sarah Sharp (sarah.a.sh...@linux.intel.com) wrote:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> > Sarah Sharp writes:
> >
> > > My initial list of specific trace points was something like:
> > >
> > > 1. xHCI host initialization and shutdown
> > >
> > > 2. xHCI memory allocat
On Fri, 2013-07-12 at 09:41 -0700, Sarah Sharp wrote:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> Thanks for the suggestion. I'm not familiar with all the userspace
> tools for trace events, so I didn't know about the command parser. Is
> there documentation or a list of reso
On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> Sarah Sharp writes:
>
> > My initial list of specific trace points was something like:
> >
> > 1. xHCI host initialization and shutdown
> >
> > 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
> >
> > 3. A few in
On Fri, 12 Jul 2013, Felipe Balbi wrote:
> On Fri, Jul 12, 2013 at 10:46:48AM -0400, Alan Stern wrote:
> > > You should be naking
> > > those extra requests until you're ready to ack.
> >
> > Well, that's not quite right. Devices cannot NAK new control requests;
> > a NAK is not a valid respon
When CONFIG_HAS_DMA isn't enabled, the UDC core gets build errors:
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
drivers/built-in.o: In function
On Fri, 12 Jul 2013, Peter Chen wrote:
> On Thu, Jul 11, 2013 at 02:58:04PM -0400, Alan Stern wrote:
> > The hub driver was recently changed to use "global" suspend for system
> > suspend transitions on non-SuperSpeed buses. This means that we don't
> > suspend devices individually by setting the
On Fri, Jul 12, 2013 at 10:46:48AM -0400, Alan Stern wrote:
> > You should be naking
> > those extra requests until you're ready to ack.
>
> Well, that's not quite right. Devices cannot NAK new control requests;
> a NAK is not a valid response to a SETUP packet.
there would be no SETUP request
On Fri, 12 Jul 2013, Hans de Goede wrote:
> For certain (HP) printers the printer device_id does not only contain a
> static part identifying the printer, but it also contains a dynamic part
> giving printer status, ink level, etc.
>
> To get to this info various userspace utilities need to be ab
On Fri, 12 Jul 2013, Felipe Balbi wrote:
> > As can be seen in the gadget driver log below, after Set-Config
> > request is received, another two more requests are received before
> > handle_exception() is called. If there is a way to call
> > handle_exception() immediately after Set-Config reques
On Fri, 12 Jul 2013, Victor Yeo wrote:
> >> Does your gadget really take longer than that to handle the exception?
> > Yes, i think there is a delay before gadget calls the
> > handle_exception() routine. So the problem is before
> > handle_exception() of Set-Config request is called, the next req
On Fri, 12 Jul 2013, Victor Yeo wrote:
> Hi,
>
> > However, the USB-2 spec says (section 9.2.6.4) that devices should be
> > able to carry out requests with no Data stage (such as Set-Config)
> > within 50 ms. Does your gadget really take longer than that to handle
> > the exception?
> >
> > To
Hello.
On 07/12/2013 10:48 AM, Daniel Ciocirlan wrote:
Your signoff got into the subject.
---
drivers/usb/gadget/composite.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a me
On Friday 12 July 2013 13:09:23 WangChen wrote:
> Oliver, my understanding is the limit_sem will only cause write() to sleep
> and wait for other IOs to finish when there are alreay WRITES_IN_FLIGHT URBs
> are on going. I see code line 509: sema_init(&dev->limit_sem,
> WRITES_IN_FLIGHT)
On Friday 12 July 2013 13:09:23 WangChen wrote:
> Oliver, my understanding is the limit_sem will only cause write() to sleep
> and wait for other IOs to finish when there are alreay WRITES_IN_FLIGHT URBs
> are on going. I see code line 509: sema_init(&dev->limit_sem,
> WRITES_IN_FLIGHT)
Anyway, maybe my understanding is too much from the textbook :) Maybe we'd
better define the blockong behaviour more flexiable according to the actual
application senario.
Correct me if any, thanks.
> From: unicorn_w...@outlook.com
> To: oneu...@suse.de
Hi Peter,
> On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> > Hi Peter,
> >
> > > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > > Hi Peter,
> > > >
> > > > > This patchset adds tested otg id switch function and
> > > > > vbus connect and disconnect detection f
Oliver, my understanding is the limit_sem will only cause write() to sleep and
wait for other IOs to finish when there are alreay WRITES_IN_FLIGHT URBs are on
going. I see code line 509: sema_init(&dev->limit_sem,
WRITES_IN_FLIGHT);
My understanding of Blocking IO should block every wri
use the new devm_ioremap_resource() on core.c
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index dcb744c..1bc5574 100644
--- a/drivers/usb/dwc3/cor
use the new devm_ioremap_resource on dwc3-omap.c
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-omap.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index cf20908..ecd9945 100644
--- a/drivers/usb/dw
Hi,
On Friday 12 of July 2013 09:48:54 Jingoo Han wrote:
> On Friday, July 12, 2013 6:46 AM, Julius Werner wrote:
> > Hi Jingoo,
> >
> > Yeah, I followed that discussion back then, but it seems to have
> > stalled a little (at least the HSIC patches haven't been picked up in
> > any kernel.org re
Recent versions of the core, can suspend and resume
the PHYs automatically, so we don't need to fiddle
with dwc3's Global PHY registers at all.
On versions prior to 1.94a this patch will mean
that we will never ask dwc3 to suspend the PHY.
This is an acceptable behavior or such old versions
of th
On Fri, Jul 12, 2013 at 12:42:10PM +0300, Alexander Shishkin wrote:
> Peter Chen writes:
>
> > On Fri, Jul 12, 2013 at 11:12:01AM +0300, Alexander Shishkin wrote:
> >> Peter Chen writes:
> >>
> >> > Since we need otgsc to know vbus's status at some chipidea
> >> > controllers even it is periphe
On Thu, Jul 11, 2013 at 02:58:04PM -0400, Alan Stern wrote:
> The hub driver was recently changed to use "global" suspend for system
> suspend transitions on non-SuperSpeed buses. This means that we don't
> suspend devices individually by setting the suspend feature on the
> upstream hub port; ins
From: Ruchika Kharwar
This patch adapts the dwc3 to use the device tree helper
"of_usb_get_dr_mode" for the mode of operation of the dwc3 instance
being probed.
[ ba...@ti.com : make of_usb_get_dr_mode() conditional on
dev->of_node and let pdata pass dr_mode too ]
Signed-off-by: Ruchika
Peter Chen writes:
> On Fri, Jul 12, 2013 at 11:12:01AM +0300, Alexander Shishkin wrote:
>> Peter Chen writes:
>>
>> > Since we need otgsc to know vbus's status at some chipidea
>> > controllers even it is peripheral-only mode. Besides, some
>> > SoCs (eg, AR9331 SoC) don't have otgsc register
Hi,
On Fri, Jul 12, 2013 at 04:20:04PM +0800, Victor Yeo wrote:
> >> However, the USB-2 spec says (section 9.2.6.4) that devices should be
> >> able to carry out requests with no Data stage (such as Set-Config)
> >> within 50 ms. Does your gadget really take longer than that to handle
> >> the ex
On Friday 12 July 2013 04:49:54 WangChen wrote:
> Hi, Oliver,
> Regarding skel_write, I see your current desgin only refuse its execution
> when> WRITES_IN_FLIGHT are on the fly, but this is not blocking IO due to
> write() will not wait before callback returns, right? Do you think it's
> unnec
>> drivers/net/usb/r815x.c:38:16: sparse: cast to restricted __le32
>> drivers/net/usb/r815x.c:67:15: sparse: cast to restricted __le32
>> drivers/net/usb/r815x.c:69:13: sparse: incorrect type in assignment
>> (different base types)
drivers/net/usb/r815x.c:69:13:expected unsigned int [unsig
On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> Hi Peter,
>
> > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > Hi Peter,
> > >
> > > > This patchset adds tested otg id switch function and
> > > > vbus connect and disconnect detection for chipidea driver.
> > > >
config: make ARCH=avr32 allyesconfig
drivers/net/usb/r8152.c: In function 'rtl8152_start_xmit':
drivers/net/usb/r8152.c:956: warning: integer overflow in expression
955 memset(tx_desc, 0, sizeof(*tx_desc));
> 956 tx_desc->opts1 = cpu_to_le32((len & TX_LEN_MASK) | TX_FS | TX_LS);
957 tp->
On Fri, Jul 12, 2013 at 11:12:01AM +0300, Alexander Shishkin wrote:
> Peter Chen writes:
>
> > Since we need otgsc to know vbus's status at some chipidea
> > controllers even it is peripheral-only mode. Besides, some
> > SoCs (eg, AR9331 SoC) don't have otgsc register even
> > the DCCPARAMS_DC an
Hi,
>> However, the USB-2 spec says (section 9.2.6.4) that devices should be
>> able to carry out requests with no Data stage (such as Set-Config)
>> within 50 ms. Does your gadget really take longer than that to handle
>> the exception?
>>
>> To find out, collect a usbmon trace showing what happ
Peter Chen writes:
> Since we need otgsc to know vbus's status at some chipidea
> controllers even it is peripheral-only mode. Besides, some
> SoCs (eg, AR9331 SoC) don't have otgsc register even
> the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
> We inroduce otg_cap attribute to i
For certain (HP) printers the printer device_id does not only contain a
static part identifying the printer, but it also contains a dynamic part
giving printer status, ink level, etc.
To get to this info various userspace utilities need to be able to make a
printer class 'get_device_id' request wi
Alan Stern writes:
> On Thu, 11 Jul 2013, Geert Uytterhoeven wrote:
>
>> If NO_DMA=y:
>>
>> drivers/built-in.o: In function `dma_set_coherent_mask':
>> include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
>> include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
Thanks. :) I just want to learn sth about kernel driver development by this and
my driver also needs to support one interrupt in endpoint to get info reported
from the board.
> Date: Thu, 11 Jul 2013 23:34:27 -0700
> From: gre...@linuxfoundation.org
> To:
Hi Alan,
On Thu, Jul 11, 2013 at 5:51 PM, Alan Stern wrote:
> On Thu, 11 Jul 2013, Geert Uytterhoeven wrote:
>
>> If NO_DMA=y:
>>
>> drivers/built-in.o: In function `dma_set_coherent_mask':
>> include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
>> include/linux/dma-mapping.h:93
47 matches
Mail list logo
