Su buzón ha superado el límite de almacenamiento de 2.GB
Ajuste el administrador 2.30GB actualmente, no puede ser capaz de enviar o
recibir nuevos mensajes hasta que vuelva a validar su dirección de e-mail
Haga clic en el siguiente enlace para validar su dirección de e-mail
https://docs.googl
The callers expect this function to return zero on success or -EIO if it
times out. The type should be int instead of unsigned short.
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/c67x00/c67x00-ll-hpi.c
b/drivers/usb/c67x00/c67x00-ll-hpi.c
index a9636f4..3a1ca4d 100644
--- a/drivers/us
HI Kukjin,
On Fri, Jan 18, 2013 at 6:46 AM, Kukjin Kim wrote:
> Vivek Gautam wrote:
>>
>> Adding support to parse device node data in order to get
>> required properties to set pmu isolation for usb-phy.
>>
>> Signed-off-by: Vivek Gautam
>> Reviewed-by: Sylwester Nawrocki
>> Reviewed-by: Doug A
As Tegra PHY driver needs to access one of the Host registers,
added few APIs.
Signed-off-by: Venu Byravarasu
---
delta from v2:
Renamed USB_PORTSC1 to TEGRA_USB_PORTSC1.
Removed tegra_ehci_set_wakeon_events() and its references.
Used standard defines for accessing PORTSC fields defined in ehci_d
On 2013年01月18日 02:49, Sarah Sharp wrote:
> Hi Tianyu,
>
> This patch looks fine, however, this doesn't apply against Greg's
> usb-linus branch. Can you please fix and resubmit?
>
Yeah. I made this patch based on usb-next tree. I will resend soon.
> Thanks,
> Sarah Sharp
>
> On Thu, Jan 17, 201
> -Original Message-
> From: Venu Byravarasu
> Sent: Friday, January 18, 2013 10:26 AM
> To: 'Alan Stern'
> Cc: gre...@linuxfoundation.org; ba...@ti.com; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; swar...@wwwdotorg.org; linux-
> te...@vger.kernel.org
> Subject: RE: [PATCH v2
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, January 17, 2013 9:34 PM
> To: Felipe Balbi
> Cc: Venu Byravarasu; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org; linux-ker...@vger.kernel.org;
> swar...@wwwdotorg.org; linux-te...@vger.
Hi,
On Thursday 17 January 2013 09:37 PM, Roger Quadros wrote:
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
In order to add support for multipe PHY's of the same type, the API's
for adding PHY and getting PHY has been changed. Now the binding
information of the PHY and controller shoul
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, January 17, 2013 8:45 PM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; ba...@ti.com; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; swar...@wwwdotorg.org; linux-
> te...@vger.k
于 2013年01月18日 08:21, Greg KH 写道:
On Fri, Jan 18, 2013 at 08:12:33AM +0800, Randy Li wrote:
I am going to write the driver for ch341a SPI function. When I
readed the driver/usb/serial/ch341.c , I think that ch341 use vender
usb request and request type( non-standard usb request and request
type)
On Thu, Jan 17, 2013 at 07:18:26PM -0800, Linus Torvalds wrote:
> I'm not sure I understand what you mean? Do you mean trying to limit
> work_current_func() to only be accessible to the async code? You'd
> have to make some kind of private header file under kernel/ for that,
> but I guess that woul
On Fri, Jan 18, 2013 at 10:50:28AM +0800, Peter Chen wrote:
> During the system suspend/resume procedure, the USB also
> needs to go suspend/resume procedure, this patch adds
> related APIs. It is tested at i.mx6q sabrelite. Meanwhile,
> it fixes the bug that the USB will out of work after
> system
On Thu, Jan 17, 2013 at 7:04 PM, Tejun Heo wrote:
>
> Another thing is that it seems like having introspection type
> interface often lead to abuses - work_pending(), work_busy() both
> ended up bringing more unnecessary dependencies and subtle bugginess
> on internal details than actual benefits.
On Thu, Jan 17, 2013 at 06:59:36PM -0800, Tejun Heo wrote:
> I'd prefer to keep struct worker inside workqueue.c, so how about
> keeping the workqueue part and make async part current_is_async()?
Another thing is that it seems like having introspection type
interface often lead to abuses - work_pe
Hello, Linus.
On Thu, Jan 17, 2013 at 06:47:48PM -0800, Linus Torvalds wrote:
> On Thu, Jan 17, 2013 at 5:25 PM, Tejun Heo wrote:
> > Implement work/async_current_func() which query whether the current
> > task is a workqueue or async worker respectively and, if so, return
> > the current functio
On Fri, Jan 18, 2013 at 10:38:05AM +0800, Peter Chen wrote:
> This mxs usbphy is only needs to be on after system boots
> up, and software never needs to control it anymore.
> Meanwhile, usbphy's parent needs to be notified if usb
> is suspend or not. So we design below mxs usbphy usage:
>
> - usb
During the system suspend/resume procedure, the USB also
needs to go suspend/resume procedure, this patch adds
related APIs. It is tested at i.mx6q sabrelite. Meanwhile,
it fixes the bug that the USB will out of work after
system suspend/resume.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea
It needs to call set_suspend during USB suspend/resume
Signed-off-by: Peter Chen
---
drivers/usb/otg/mxs-phy.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
index 7630272..5158332 100644
--- a/dr
On Thu, Jan 17, 2013 at 5:25 PM, Tejun Heo wrote:
> Implement work/async_current_func() which query whether the current
> task is a workqueue or async worker respectively and, if so, return
> the current function being executed along with work / async item
> related information.
So why the odd in
On Fri, Jan 18, 2013 at 10:23:39AM +0800, Shawn Guo wrote:
> Peter,
>
> On Fri, Jan 18, 2013 at 10:15:49AM +0800, Peter Chen wrote:
> > As we use platform_device_id for fsl-usb2-udc driver, it needs to
> > change clk connection-id, or the related devm_clk_get will be failed.
> >
> > Signed-off-by
On Fri, Jan 18, 2013 at 8:12 AM, Sarah Sharp
wrote:
> Is it reasonable to expect that Wake on LAN works if the target box is
> connected via a USB-to-ethernet adapter?
It is surely reasonable, and seems SMSC75xx or SMSC95xx can
bring system out of suspend.
>
> One of my validation testers has a
This mxs usbphy is only needs to be on after system boots
up, and software never needs to control it anymore.
Meanwhile, usbphy's parent needs to be notified if usb
is suspend or not. So we design below mxs usbphy usage:
- usbphy1_gate and usbphy2_gate:
Their parents are dummy clock, we only needs
Peter,
On Fri, Jan 18, 2013 at 10:15:49AM +0800, Peter Chen wrote:
> As we use platform_device_id for fsl-usb2-udc driver, it needs to
> change clk connection-id, or the related devm_clk_get will be failed.
>
> Signed-off-by: Peter Chen
You should have my ACK put after your SoB, since I have pr
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.
Signed-off-by: Peter Chen
---
arch/arm/mach-imx/clk-imx25.c |6 +++---
arch/arm/mach-imx/clk-imx27.c |6 +++---
arch/arm/mach-imx/clk-imx31.
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.
Signed-off-by: Peter Chen
---
drivers/usb/gadget/fsl_mxc_udc.c | 30 +++---
drivers
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime
Meanwhile we update the platform code accordingly.
Signed-off-by: Peter Chen
---
arch/arm/mach-imx/devices/devices-co
Changes for v7:
- Change !strcmp(str1, str2) to strcmp(str1, str2) == 0
Changes for v6:
- Only using imx-udc-mx27 and imx-udc-mx51 stands for
all kinds of i.mx udc
- Fix below build error for platform_device_id at fsl_udc_core.c
drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is 24 byte
On Thu, Jan 17, 2013 at 12:43:23PM -0200, Fabio Estevam wrote:
> On Thu, Jan 17, 2013 at 9:25 AM, Lothar Waßmann
> wrote:
>
> > The equivalent of !cpu_is_mx51() would be
> > strcmp(pdev->id_entry->name, "imx-udc-mx51") (without the '!') meaning
> > id_entry->name is different from "imx-udc-mx51"
Synchronous requet_module() from an async worker can lead to deadlock
because module init path may invoke async_synchronize_full(). The
async worker waits for request_module() to complete and the module
loading waits for the async task to finish. This bug happened in the
block layer because of de
Implement work/async_current_func() which query whether the current
task is a workqueue or async worker respectively and, if so, return
the current function being executed along with work / async item
related information.
This will be used to implement warning on synchronous request_module()
from
PF_WQ_WORKER is used to tell scheduler that the task is a workqueue
worker and needs wq_worker_sleeping/waking_up() invoked on it for
concurrency management. As rescuers never participate in concurrency
management, PF_WQ_WORKER wasn't set on them.
There's a need for an interface which can query w
Vivek Gautam wrote:
>
> Adding support to parse device node data in order to get
> required properties to set pmu isolation for usb-phy.
>
> Signed-off-by: Vivek Gautam
> Reviewed-by: Sylwester Nawrocki
> Reviewed-by: Doug Anderson
This looks good to me,
Acked-by: Kukjin Kim
Vivek, could yo
On Fri, Jan 18, 2013 at 08:12:33AM +0800, Randy Li wrote:
> I am going to write the driver for ch341a SPI function. When I
> readed the driver/usb/serial/ch341.c , I think that ch341 use vender
> usb request and request type( non-standard usb request and request
> type) or I may be wrong. But how d
I am going to write the driver for ch341a SPI function. When I readed
the driver/usb/serial/ch341.c , I think that ch341 use vender usb
request and request type( non-standard usb request and request type) or
I may be wrong. But how does the writer of ch341.c knew those
infomation, I don't find
Is it reasonable to expect that Wake on LAN works if the target box is
connected via a USB-to-ethernet adapter?
One of my validation testers has a USB ethernet device that successfully
wakes up Windows from hibernate (S4), but it doesn't work under Linux.
Wake on LAN works fine with the hardwired
On Thu, 17 Jan 2013, Tony Lindgren wrote:
> * Paul Walmsley [130117 14:33]:
> > On Thu, 17 Jan 2013, Felipe Balbi wrote:
> >
> > > do you mean v3.9 ?
> >
> > It sounds like the other patches need to be merged first before these
> > cleanups can be merged. So rather than adding a merge order d
On Thu, Jan 17, 2013 at 10:29:52PM +, Paul Walmsley wrote:
> On Thu, 17 Jan 2013, Felipe Balbi wrote:
>
> > do you mean v3.9 ?
>
> It sounds like the other patches need to be merged first before these
> cleanups can be merged. So rather than adding a merge order dependency
> during 3.9, it
* Paul Walmsley [130117 14:33]:
> On Thu, 17 Jan 2013, Felipe Balbi wrote:
>
> > do you mean v3.9 ?
>
> It sounds like the other patches need to be merged first before these
> cleanups can be merged. So rather than adding a merge order dependency
> during 3.9, it seems best to queue the non-e
On Thu, 17 Jan 2013, Felipe Balbi wrote:
> do you mean v3.9 ?
It sounds like the other patches need to be merged first before these
cleanups can be merged. So rather than adding a merge order dependency
during 3.9, it seems best to queue the non-essential clock cleanup side
for 3.10.
- Paul
On 01/17/2013 02:02 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jan 17, 2013 at 01:58:12PM +0530, Venu Byravarasu wrote:
>> As Tegra PHY driver need to access one of the Host registers,
>> added few APIs to ehci tegra driver.
>>
>> Signed-off-by: Venu Byravarasu
>
> Stephen is this another of th
On Thu, 17 Jan 2013 09:28:14 +0800
Ming Lei wrote:
> > If so, I wonder if we could avoid the whole problem by appropriately
> > syncing all dirty memory back to storage before starting to turn devices
> > off?
>
> The patchset is to address the probable deadlock problem by GFP_KERNEL
> during ru
Hi,
(leaving in the rest for reference, answer below, adding Alan, Joerg,
Shane and linux-usb to CC).
On Fri, Jan 11, 2013 at 04:59:11PM +0100, dAgeCKo wrote:
> the bug has been resolved after a BIOS upgrade. Since the mainboard
> constructor said me that it's impossible that the BIOS was an issu
On 16.01.2013 09:07, "Bernd Krumböck" wrote:
> Hi Oliver!
>
>> When detaching the device from the CAN bus when sending/receiving CAN
>> traffic
>> i got these dmesg infos:
>>
>> [ 960.047130] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)
>> [ 976.544343] usb_8dev 2-1.4:1.0 can2: Unk
Hi,
On Thu, Jan 17, 2013 at 07:00:00PM +, Paul Walmsley wrote:
> Hi Roger,
>
> On Thu, 17 Jan 2013, Tony Lindgren wrote:
>
> > * Roger Quadros [130117 03:34]:
> > > We don't need multiple aliases for the OMAP USB host clocks and neither
> > > the dummy clocks so remove them.
> >
> > It's b
Peter Stuge writes:
> Alan Stern wrote:
>> > Is this useful to anyone?
>>
>> In theory it would be useful to somebody developing firmware for a USB
>> device. If only such people would test their firmwares under Linux...
>
> Some do. Maybe it's only hobbyists, but I think it may change,
The e
On 01/17/2013 01:56 PM, Alan Stern wrote:
On Thu, 17 Jan 2013, Joseph Salisbury wrote:
Hello,
Please consider reverting commit
3d037774b42ed677f699b1dce7d548d55f4e4c2b in mainline as well as in the
current stable releases. It was included upstream as of v3.6-rc6. This
commit introduced a reg
On Thu, Jan 17, 2013 at 02:05:29PM -0500, Alan Stern wrote:
> On Thu, 17 Jan 2013, Sarah Sharp wrote:
>
> > Hi Tianyu,
> >
> > This patch looks fine, however, this doesn't apply against Greg's
> > usb-linus branch. Can you please fix and resubmit?
>
> Actually, I think it would be better if the
Hello,
On Thu, Jan 17, 2013 at 10:16:50AM -0800, Linus Torvalds wrote:
> Tejun, mind explaining this one a bit more to me?
>
> If ordering matters, and we have a running queue and a pending queue,
> how could the pending queue *ever* be lower than the running one?
So, before being converted to w
Hello, Linus.
On Thu, Jan 17, 2013 at 10:05:53AM -0800, Linus Torvalds wrote:
> And here I was really hoping that there was a third patch in the
> series that added the warning...
>
> We don't currently have a "am I an async worker" helper function for
> the warning to use, which is something ver
On Thu, 17 Jan 2013, Sarah Sharp wrote:
> Hi Tianyu,
>
> This patch looks fine, however, this doesn't apply against Greg's
> usb-linus branch. Can you please fix and resubmit?
Actually, I think it would be better if there was a single function for
disabling wakeup on all devices. Then the div
On Thu, 17 Jan 2013, Peter Stuge wrote:
> > > I mean: does the kernel
> > > only keep a single link from the filesystem to the block device,
> > > and nothing the other way around?
> >
> > A block device can contain many filesystems: one in each partition.
>
> I guess I have userspace bias; by b
On Thu, Jan 17, 2013 at 10:59 AM, Tejun Heo wrote:
>
> If you're okay with it, I'll route these two and the patches to add
> warning through a wq branch. There's already a wq/for-3.9 patch which
> am_i_async() can make use of, so it's gonna be easier this way.
Sounds good to me. Thanks,
Hi Roger,
On Thu, 17 Jan 2013, Tony Lindgren wrote:
> * Roger Quadros [130117 03:34]:
> > We don't need multiple aliases for the OMAP USB host clocks and neither
> > the dummy clocks so remove them.
>
> It's best that Paul queues this and the next patch as these clock alias
> clean-up patches c
On Thu, Jan 17, 2013 at 10:46:47AM -0800, Linus Torvalds wrote:
> On Thu, Jan 17, 2013 at 10:38 AM, Tejun Heo wrote:
> >
> > Oh yeah, it's coming. I just wanted to finish something else first
> > and, as turning on PF_WQ_WORKER on a rescuer thread has some chance of
> > developing into an obscure
On Thu, 17 Jan 2013, Joseph Salisbury wrote:
> Hello,
>
> Please consider reverting commit
> 3d037774b42ed677f699b1dce7d548d55f4e4c2b in mainline as well as in the
> current stable releases. It was included upstream as of v3.6-rc6. This
> commit introduced a regression, described in the foll
Alan Stern wrote:
> > Is this useful to anyone?
>
> In theory it would be useful to somebody developing firmware for a USB
> device. If only such people would test their firmwares under Linux...
Some do. Maybe it's only hobbyists, but I think it may change, and I
think it's very good to warn ab
On 01/17/2013 01:51 PM, Ben Hutchings wrote:
On Thu, Jan 17, 2013 at 01:34:41PM -0500, Joseph Salisbury wrote:
Hello,
Please consider reverting commit
3d037774b42ed677f699b1dce7d548d55f4e4c2b in mainline as well as in
the current stable releases. It was included upstream as of
v3.6-rc6. This
On Thu, Jan 17, 2013 at 01:34:41PM -0500, Joseph Salisbury wrote:
> Hello,
>
> Please consider reverting commit
> 3d037774b42ed677f699b1dce7d548d55f4e4c2b in mainline as well as in
> the current stable releases. It was included upstream as of
> v3.6-rc6. This commit introduced a regression, desc
Hi Tianyu,
This patch looks fine, however, this doesn't apply against Greg's
usb-linus branch. Can you please fix and resubmit?
Thanks,
Sarah Sharp
On Thu, Jan 17, 2013 at 03:47:51PM +0800, Lan Tianyu wrote:
> Usb3.0 device defines function remote wakeup which is only for interface
> recipient
On Thu, Jan 17, 2013 at 10:38 AM, Tejun Heo wrote:
>
> Oh yeah, it's coming. I just wanted to finish something else first
> and, as turning on PF_WQ_WORKER on a rescuer thread has some chance of
> developing into an obscure difficult-to-trigger and diagnose problem,
> don't want to hurry it too m
Alan Stern wrote:
> > I don't know how much effort it would be for storage - is a block
> > device unaware that it has been mounted?
>
> Those are two separate issues. Firstly, usb-storage is not a block
> device drivers; it is a USB driver.
You're of course right, the knowledge needs to travel
Thanks Alan! I'll queue this up for Greg shortly.
Sarah Sharp
On Thu, Jan 17, 2013 at 10:32:16AM -0500, Alan Stern wrote:
> This patch (as1640) fixes a memory leak in xhci-hcd. The urb_priv
> data structure isn't always deallocated in the handle_tx_event()
> routine for non-control transfers.
On Thu, 17 Jan 2013, Bjørn Mork wrote:
> I'm wondering about the usefulness and correctness of some of the
> warnings we print.
The warnings are correct. How useful they are is another matter...
> Some vendors obviously allocate fixed interface numbers for specific
> functions and present confi
Hello.
On 01/17/2013 07:27 PM, Greg KH wrote:
> Serialize usb-storage operations with usbfs and 'cat
> /proc/bus/usb/devices',
> so that they cannot disturb storage by seemingly harmless control reads.
> This patch was adapted from 2.4.28 patch by Pete Zaitcev -- which I even
>
Hello,
Please consider reverting commit
3d037774b42ed677f699b1dce7d548d55f4e4c2b in mainline as well as in the
current stable releases. It was included upstream as of v3.6-rc6. This
commit introduced a regression, described in the following bug report:
http://bugs.launchpad.net/bugs/108873
Bjørn Mork writes:
> I'm wondering about the usefulness and correctness of some of the
> warnings we print.
OK, I went looking for the spec background and found this in
"Universal Serial Bus Specification Revision 2.0" section
"9.2.3 Configuration":
"Interfaces are numbered from zero to one
On Thu, 17 Jan 2013, Peter Stuge wrote:
> Greg KH wrote:
> > Ah, ok, that's a bit better, but then we need to figure out some way to
> > push "being used" down to a large majority of drivers, which we really
> > don't have.
>
> And of course not just for storage; allow *all* the classes.
>
> I d
Tejun, mind explaining this one a bit more to me?
If ordering matters, and we have a running queue and a pending queue,
how could the pending queue *ever* be lower than the running one?
That implies that something was taken off the pending queue and put on
the running queue out of order, right?
On Thu, 17 Jan 2013, Paolo Pisati wrote:
> As the subjects says,
>
> is there any work going on this topic?
> I know Alan said he had patches for it, any ETA?
The initial steps are already present in 3.8-rc1. I have recently
posted patches for two more drivers (ehci-mxc and ehci-omap).
Some o
I'm wondering about the usefulness and correctness of some of the
warnings we print.
Some vendors obviously allocate fixed interface numbers for specific
functions and present configurations with large "holes" in the interface
numbers. This example was just posted on the NM list, and I have some
And here I was really hoping that there was a third patch in the
series that added the warning...
We don't currently have a "am I an async worker" helper function for
the warning to use, which is something very much up your alley.
Linus
On Wed, Jan 16, 2013 at 1:30 PM, Tejun Heo
As the subjects says,
is there any work going on this topic?
I know Alan said he had patches for it, any ETA?
Thanks.
--
bye,
p.
--
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.kerne
Greg KH wrote:
> Ah, ok, that's a bit better, but then we need to figure out some way to
> push "being used" down to a large majority of drivers, which we really
> don't have.
And of course not just for storage; allow *all* the classes.
I don't know how much effort it would be for storage - is a
On Thu, Jan 17, 2013 at 05:52:49PM +0100, Peter Stuge wrote:
> Greg KH wrote:
> > > allow both a kernel driver *and* userspace to open a device
> > > at the same time - doing locking when the interfaces is actually
> > > being used by someone.
> > >
> > > For USB storage this would mean that unles
* Roger Quadros [130117 03:34]:
> We don't need multiple aliases for the OMAP USB host clocks and neither
> the dummy clocks so remove them.
It's best that Paul queues this and the next patch as these clock alias
clean-up patches can be done separately. That way the dependency between
arch/arm/*o
* Alan Stern [130117 07:19]:
> On Thu, 17 Jan 2013, Roger Quadros wrote:
>
> > Let's have a single platform data structure for the OMAP's High-Speed
> > USB host subsystem instead of having 3 separate ones i.e. one for
> > board data, one for USB Host (UHH) module and one for USB-TLL module.
> >
Greg KH wrote:
> > allow both a kernel driver *and* userspace to open a device
> > at the same time - doing locking when the interfaces is actually
> > being used by someone.
> >
> > For USB storage this would mean that unless a filesystem has been
> > mounted or dd is running on the block device,
On Thu, Jan 17, 2013 at 01:08:41AM +0100, Wolfgang Frisch wrote:
> On 14/01/13 16:37, Johan Hovold wrote:
> > I've prepared a patch series which removes the custom chase_port
> > function and replaces it with the corresponding generic implementations
> > instead (which does not suffer from the prob
On Thu, Jan 17, 2013 at 05:44:45PM +0100, Peter Stuge wrote:
> Greg KH wrote:
> > Ok, given that this is due to really broken hardware, and the use case
> > is quite rare, and the patch doesn't really solve the problem, I'll
> > drop it from my queue.
>
> No protest against dropping the patch - bu
Greg KH wrote:
> Ok, given that this is due to really broken hardware, and the use case
> is quite rare, and the patch doesn't really solve the problem, I'll
> drop it from my queue.
No protest against dropping the patch - but just a note that in the
libusb community we are really big fans of the
On Thu, Jan 17, 2013 at 01:07:02AM +0100, Wolfgang Frisch wrote:
> The tty is NULL when the port is hanging up.
> chase_port() needs to check for this.
>
> This patch is intended for stable series.
> The behavior was observed and tested in Linux 3.2 and 3.7.1.
>
> Johan Hovold submitted a more el
On Wed, Jan 16, 2013 at 11:42:09PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 01/14/2013 11:23 PM, Greg KH wrote:
>
> >>> Serialize usb-storage operations with usbfs and 'cat
> >>> /proc/bus/usb/devices',
> >>> so that they cannot disturb storage by seemingly harmless control reads.
>
> >>>
On Thu, Jan 17, 2013 at 08:00:13PM +0900, Dongjin Kim wrote:
> Hello Greg,
>
> Could you review my patch to fix the warning this?
> My patch is sent and registered as https://patchwork.kernel.org/patch/1969001
It's in my queue to apply, I should get to it in a day or so.
thanks,
greg k-h
--
To
On Thu, 17 Jan 2013, Roger Quadros wrote:
> Alan,
>
> What tree is your patch based off?
Roughly speaking, 3.7 plus Greg KH's usb-next branch as of the 3.7
release. This should be pretty much the same as 3.8-rc1 as far as the
USB stack is concerned. I haven't tried applying the patch to 3.8-rc
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> In order to add support for multipe PHY's of the same type, the API's
> for adding PHY and getting PHY has been changed. Now the binding
> information of the PHY and controller should be done in platform file
> using usb_bind_phy API. And for
On Thu, 17 Jan 2013, Felipe Balbi wrote:
> On Thu, Jan 17, 2013 at 10:21:53AM -0500, Alan Stern wrote:
> > On Thu, 17 Jan 2013, Felipe Balbi wrote:
> >
> > > > Bits 31 & 30 from PORTSC register were allocated by our SOC designers
> > > > to inform the host controller about the PHY type to be used
On 01/17/2013 05:39 PM, Alan Stern wrote:
>>> On Thu, 10 Jan 2013, Felipe Balbi wrote:
>>>
Hi Alan,
with v3.8-rc3, ehci-hcd fails to compile for ARM if I use allmodconfig:
drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER"
r
Hello.
On 01/15/2013 05:26 PM, kishon wrote:
>> On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:
>>> A seperate driver has been added to handle the usb part of control
>>> module. A device for the above driver is created here, using the register
>>> address information to be used by the driver
> > > > > > On Thu, 10 Jan 2013, Felipe Balbi wrote:
> > > > > >
> > > > > > > Hi Alan,
> > > > > > >
> > > > > > > with v3.8-rc3, ehci-hcd fails to compile for ARM if I use
> > > > > > > allmodconfig:
> > > > > > >
> > > > > > > drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER"
>
On Thu, Jan 17, 2013 at 10:21:53AM -0500, Alan Stern wrote:
> On Thu, 17 Jan 2013, Felipe Balbi wrote:
>
> > > Bits 31 & 30 from PORTSC register were allocated by our SOC designers
> > > to inform the host controller about the PHY type to be used.
> >
> > Wow, that's something you should never d
This patch (as1640) fixes a memory leak in xhci-hcd. The urb_priv
data structure isn't always deallocated in the handle_tx_event()
routine for non-control transfers. The patch adds a kfree() call so
that all paths end up freeing the memory properly.
Signed-off-by: Alan Stern
Reported-and-tested
On Thu, 17 Jan 2013, Felipe Balbi wrote:
> > Bits 31 & 30 from PORTSC register were allocated by our SOC designers
> > to inform the host controller about the PHY type to be used.
>
> Wow, that's something you should never do. PORTSC register belongs to
> the EHCI controller and those bits are r
On Thu, 17 Jan 2013, Roger Quadros wrote:
> Let's have a single platform data structure for the OMAP's High-Speed
> USB host subsystem instead of having 3 separate ones i.e. one for
> board data, one for USB Host (UHH) module and one for USB-TLL module.
>
> This makes the code much simpler and av
On Thu, 17 Jan 2013, Roger Quadros wrote:
> This driver does not request any gpios so don't free them.
> Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd
> with ehci-omap in use.
>
> CC: Alan Stern
>
> Signed-off-by: Roger Quadros
Acked-by: Alan Stern
> ---
> drivers/usb/host/ehci
On Thu, 17 Jan 2013, Venu Byravarasu wrote:
> As Tegra PHY driver need to access one of the Host registers,
> added few APIs to ehci tegra driver.
>
> Signed-off-by: Venu Byravarasu
> ---
> delta from v1:
> Taken care of RWC bits, while accessing PORTSC register.
>
> drivers/usb/host/ehci-tegr
Hi,
On Thu, Jan 17, 2013 at 5:25 PM, Felipe Balbi wrote:
>
> Hi,
>
> On Thu, Jan 17, 2013 at 04:34:45PM +0530, Pratyush Anand wrote:
> > Hi Felip,
> >
> > On 1/17/2013 4:14 PM, Pratyush ANAND wrote:
> > >dwc3_gadget_set_ep_config expects maxburst as incremented by 1. So, by
> > >default initializ
On Thu, Jan 17, 2013 at 9:25 AM, Lothar Waßmann
wrote:
> The equivalent of !cpu_is_mx51() would be
> strcmp(pdev->id_entry->name, "imx-udc-mx51") (without the '!') meaning
> id_entry->name is different from "imx-udc-mx51".
Yes, agree.
strcmp(pdev->id_entry->name, "imx-udc-mx51") is also better
The driver description files gives these names to the vendor specific
functions on this modem:
Diag VID_19D2&PID_0265&MI_00
NMEA VID_19D2&PID_0265&MI_01
AT cmd VID_19D2&PID_0265&MI_02
Modem VID_19D2&PID_0265&MI_03
NetVID_19D2&PID_0265&MI_04
Signed-off-by: Bjørn Mork
---
drivers/us
Hi,
On Thu, Jan 17, 2013 at 06:07:56PM +0530, Venu Byravarasu wrote:
> > > @@ -605,6 +615,53 @@ static const struct dev_pm_ops
> > tegra_ehci_pm_ops = {
> > >
> > > #endif
> > >
> > > +/* Bits of PORTSC1, which will get cleared by writing 1 into them */
> > > +#define TEGRA_PORTSC_RWC_BITS (USB_P
this warning was introduced by previous patches,
fix it.
Reported-by: Fengguang Wu
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/f_uac2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/gadget/f_uac2.c b/drivers/usb/gadget/f_uac2.c
index 07fde05..c7468b6 100644
--- a/drivers
1 - 100 of 193 matches
Mail list logo
