On Thu, Aug 9, 2012 at 4:16 AM, Rafael J. Wysocki wrote:
> On Wednesday, August 08, 2012, Alan Stern wrote:
To be honest, I agree on the idea:
The runtime-resume method does nothing but bring the device
back to full power; it doesn't do any other processing, which
should b
Hello Michal,
On Thu, Aug 9, 2012 at 12:55 AM, Michal Nazarewicz wrote:
> Kernel Newbie writes:
>> In the 3.4 kernel, we have observed that the RNDIS function driver clears
>> the string id reference to 0 during unbind. And, during bind, we see that
>> the rndis_init() itself is initiated only w
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Thursday, August 09, 2012 3:12 AM
> To: Bhupesh SHARMA
> Cc: linux-usb@vger.kernel.org; ba...@ti.com
> Subject: Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to
> use v
Hi Alan and Laurent,
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, August 09, 2012 7:20 AM
> To: Laurent Pinchart
> Cc: Bhupesh SHARMA; linux-usb@vger.kernel.org; ba...@ti.com
> Subject: Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadg
On 2012/8/9 5:30, Moore, Robert wrote:
I have a comment about the existing _PLD support in Linux.
It uses bitfields, and these are known to not be reliable when using them to
extract bits from a predefined bit-packed data structure. (different compilers
implement bitfields differently, and the
On 2012/8/9 5:22, Sarah Sharp wrote:
Hi Tianyu,
I was talking to Alan Cox about the port power off mechanism, and he
suggested it might be good to expose the power resource information to
userspace via sysfs. Then the user could figure out which of their
devices are connected to which power res
Add device tree files for VT8500, WM8505 and WM8650 SoC's and
reference boards.
Signed-off-by: Tony Prisk
---
arch/arm/boot/dts/vt8500-bv07.dts | 31 +
arch/arm/boot/dts/vt8500.dtsi | 99 +
arch/arm/boot/dts/wm8505-ref.dts | 31 +
arch/arm/b
This patchset updates arch-vt8500 to devicetree and removes all the old-style
code. Support for WM8650 has also been added.
Example dts/dtsi files are given for the three currently supported models.
Major changes:
GPIO code has been converted to a platform_device and rewritten as WM8505
support
Signed-off-by: Tony Prisk
---
drivers/rtc/rtc-vt8500.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 9e94fb1..07bf193 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -23,6 +23,7 @@
Update vt8500-fb, wm8505-fb and wmt-ge-rops to support device
tree bindings.
Small change in wm8505-fb.c to support WM8650 framebuffer color
format.
Signed-off-by: Tony Prisk
---
drivers/video/Kconfig |6 +--
drivers/video/vt8500lcdfb.c | 79 ++-
drive
Signed-off-by: Tony Prisk
---
drivers/tty/serial/vt8500_serial.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 2be006f..dee6715 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/dri
Add devicetree support for vt8500-ehci.
Convert vt8500-uhci to a generic non-pci platform-uhci with
device tree support.
Signed-off-by: Tony Prisk
---
drivers/usb/host/Kconfig |4 +-
drivers/usb/host/ehci-vt8500.c | 25 --
drivers/usb/host/uhci-hcd.c |5 ++
drivers/u
Converted the existing arch-vt8500 gpio to a platform_device.
Added support for WM8505 and WM8650 GPIO controllers.
Signed-off-by: Tony Prisk
---
drivers/gpio/Kconfig |6 +
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-vt8500.c | 313 ++
Bindings for gpio, interrupt controller, power management controller,
timer, realtime clock, serial uart, ehci and uhci controllers and
framebuffer controllers used on the arch-vt8500 platform.
Framebuffer binding also specifies a 'display' node which is required
for determining the lcd panel data
On Thu, 9 Aug 2012, Laurent Pinchart wrote:
> Hi Alan,
>
> On Wednesday 08 August 2012 21:31:12 Alan Stern wrote:
> > On Wed, 8 Aug 2012, Laurent Pinchart wrote:
> > > I guess it depends on the usb_ep_dequeue() API. The function documentation
> > > doesn't clearly state whether calling it with an
Hi Alan,
On Wednesday 08 August 2012 21:31:12 Alan Stern wrote:
> On Wed, 8 Aug 2012, Laurent Pinchart wrote:
> > I guess it depends on the usb_ep_dequeue() API. The function documentation
> > doesn't clearly state whether calling it with an already dequeuing request
> > is valid (in which case it
On Wed, 8 Aug 2012, Laurent Pinchart wrote:
> I guess it depends on the usb_ep_dequeue() API. The function documentation
> doesn't clearly state whether calling it with an already dequeuing request is
> valid (in which case it should return an error, possibly print a debug
> message, but not a
From: "Rémi Denis-Courmont"
Date: Wed, 8 Aug 2012 10:12:06 +0300
> Le mercredi 8 août 2012 00:56:26 Jesper Juhl, vous avez écrit :
>> We allocate memory for 'req' with usb_alloc_urb() and then test
>> 'if (!req || rx_submit(pnd, req, GFP_KERNEL | __GFP_COLD))'.
>> If we enter that branch due to '
On Wednesday, August 08, 2012, Ming Lei wrote:
> On Wed, Aug 8, 2012 at 4:45 AM, Rafael J. Wysocki wrote:
> > On Tuesday, August 07, 2012, Ming Lei wrote:
> >> On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki wrote:
[...]
> >
> >> and you want to move something out of previous .runtime_resume
>
Hi Bhupesh,
On Thursday 09 August 2012 01:19:49 Bhupesh SHARMA wrote:
> On Wednesday, August 08, 2012 5:32 PM Laurent Pinchart wrote:
> > On Tuesday 07 August 2012 23:07:56 Bhupesh SHARMA wrote:
> > > On Tuesday, August 07, 2012 8:23 PM Laurent Pinchart wrote:
> > > > On Tuesday 31 July 2012 06:24
I understand if it takes a while as it's a complex one off problem. I just
wanted to be sure we were on the same page and that I was being clear about
what worked and what didn't.
Regards,
Matthew.
On Wed, Aug 08, 2012 at 02:03:14PM -0700, Sarah Sharp wrote:
> Hi Matthew,
>
> This patch does f
I have a comment about the existing _PLD support in Linux.
It uses bitfields, and these are known to not be reliable when using them to
extract bits from a predefined bit-packed data structure. (different compilers
implement bitfields differently, and there are also endian considerations.)
We a
Hi Tianyu,
I was talking to Alan Cox about the port power off mechanism, and he
suggested it might be good to expose the power resource information to
userspace via sysfs. Then the user could figure out which of their
devices are connected to which power resources. For example, users
could move
Hi Matthew,
This patch does fix the error that Gary reported. And even though it
doesn't completely fix your issue, it did make the same error messages
Gary was seeing go away.
I'll still be looking at your logs, but I'm leaving on vacation this
Friday, so I'm not sure if we'll have time to solv
On Wednesday, August 08, 2012, Alan Stern wrote:
> On Wed, 8 Aug 2012, Ming Lei wrote:
[...]
> > If so, I am wondering why the 'func' can't be called in .runtime_resume
> > directly, and follow the below inside caller at the same time?
> >
> > if (device is active or disabled)
> >
Hi Sarah,
If I am reading right, this patch is not any different from the one we were
trying to get my card reader to work on USB 3.0.
I did some further testing last with the same card, reader, and exfat driver
on a USB 2.0 port on the same machine and everything worked with no errors in
dmes
When we encounter an xHCI host that needs the XHCI_TRUST_TX_LENGTH
quirk, the xHCI driver ends up spewing messages about the quirk into
dmesg every time a short packet occurs. Change the xHCI driver to
rate-limit such warnings.
Signed-off-by: Sarah Sharp
Reported-by: Matthew Hall
Reported-by: G
Gary reports that with recent kernels, he notices more xHCI driver
warnings:
xhci_hcd :03:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?
We think his Etron xHCI host controller may have the same buggy behavior
as the Fresco Logic xHCI host. When a short tran
This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches. The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.
The first thing to note is that a Set TR Dequeue Point
The NEC/Renesas 720201 xHCI host controller does not complete its reset
within 250 milliseconds. In fact, it takes about 9 seconds to reset the
host controller, and 1 second for the host to be ready for doorbell
rings. Extend the reset and CNR polling timeout to 10 seconds each.
This patch shoul
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
for-usb-linus-2012-08-08
for you to fetch changes up to 50d0206fcaea3e
Kernel Newbie writes:
> In the 3.4 kernel, we have observed that the RNDIS function driver clears
> the string id reference to 0 during unbind. And, during bind, we see that
> the rndis_init() itself is initiated only when the RNDIS string id reference
> is 0. Is this ok?
>
> The issue behind this
On Wednesday 08 August 2012, Stephen Warren wrote:
> I think that's all just:
>
> module_platform_driver(vt8500_gpio_driver);
>
> (except that _init uses platform_driver_probe() rather than
> platform_driver_register(), which seems unusual. I guess that explains
> the of_find_matching_node() abov
On 08/07/2012 07:39 PM, Tony Prisk wrote:
> Merged existing board files to a single dt-capable file.
> Converted irq and timer code to devicetree.
> Removed existing device files that are no longer required with
> devicetree support.
>
> All existing platform devices are converted to devicetree nod
On 08/07/2012 07:39 PM, Tony Prisk wrote:
> Update vt8500-fb, wm8505-fb and wmt-ge-rops to support device
> tree bindings.
> Small change in wm8505-fb.c to support WM8650 framebuffer color
> format.
That might warrant a separate patch?
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/v
On 08/07/2012 07:39 PM, Tony Prisk wrote:
> Add device tree files for VT8500, WM8505 and WM8650 SoC's and
> reference boards.
> diff --git a/arch/arm/boot/dts/vt8500_ref.dts
> b/arch/arm/boot/dts/vt8500_ref.dts
It appears more typical to use "-" rather than "_" in the filename to
join SoC and bo
On Wed, 8 Aug 2012, Ming Lei wrote:
> On Wed, Aug 8, 2012 at 4:45 AM, Rafael J. Wysocki wrote:
> > On Tuesday, August 07, 2012, Ming Lei wrote:
> >> On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki wrote:
> >> >> Yes, I agree, but I don't think it may make .runtime_post_resume
> >> >> not doabl
Hello,
I am getting the following kernel oops (http://paste.debian.net/182812/)
sporadically. Kernel version is 3.2.14.
Code basically does the following:
ioctl(fd,HIDIOCSUSAGES, &ref_multi_u);
ioctl(fd,HIDIOCSREPORT, &rep_info_u);
Here are some notes:
1. Happens in implement() function cal
On 08/07/2012 07:39 PM, Tony Prisk wrote:
> Converted the existing arch-vt8500 gpio to a platform_device.
> Added support for WM8505 and WM8650 GPIO controllers.
> diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
> +static struct of_device_id vt8500_gpio_dt_ids[] = {
> + {
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Wednesday, August 08, 2012 5:32 PM
> To: Bhupesh SHARMA
> Cc: linux-usb@vger.kernel.org; ba...@ti.com
> Subject: Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to
> use
On Tue, 7 Aug 2012, Tomas Sokorai wrote:
> On Tue, Aug 7, 2012 at 3:42 PM, Alan Stern wrote:
> >
> > I don't have time today to look further into this, but I'll get back to
> > you later.
>
> No hurries, in fact I was gathering a bit more info about this behavior.
> I dumped the ed_rm_list when
On 08/08/2012 03:30 PM, Olivier Sobrie wrote:
> On Wed, Aug 08, 2012 at 10:25:35AM +0200, Wolfgang Grandegger wrote:
>> Hi Oliver,
>>
>> On 08/08/2012 08:14 AM, Olivier Sobrie wrote:
>>> Hi Wolfgang,
>>>
>>> On Tue, Aug 07, 2012 at 08:26:38AM +0200, Wolfgang Grandegger wrote:
On 08/06/2012 07:
Thanks for the confirmation. I will try and update you.
Dineshkumar
--
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
On Wed, 8 Aug 2012, Dineshkumar wrote:
> Hi,
> I am trying enable remote wakeup functionality using gadgetfs. But
> initialization fails with invalid argument. I have read from one of the
> threads
> in this forum that confirms this behavior. Now, my doubt is how to achieve
> remote wakeup using
On Wed, Aug 8, 2012 at 11:19 AM, Arnd Bergmann wrote:
>> What on earth are all those magic numbers?
>>
>> I *guess* they're enabling some default GPIO settings etc.
>
> No, they are the register offsets you quoted above, per bank.
Aha I was fooled by this:
+struct vt8500_gpio_bank_regs {
+
Hi,
I am trying enable remote wakeup functionality using gadgetfs. But
initialization fails with invalid argument. I have read from one of the threads
in this forum that confirms this behavior. Now, my doubt is how to achieve
remote wakeup using gadgetfs? Is there any work around for this?
.bmAttr
On Wed, Aug 08, 2012 at 10:25:35AM +0200, Wolfgang Grandegger wrote:
> Hi Oliver,
>
> On 08/08/2012 08:14 AM, Olivier Sobrie wrote:
> > Hi Wolfgang,
> >
> > On Tue, Aug 07, 2012 at 08:26:38AM +0200, Wolfgang Grandegger wrote:
> >> On 08/06/2012 07:21 AM, Olivier Sobrie wrote:
> >>> This driver pr
hi all:
when I study inc_deq in xhci-ring.c, why we need to announce and
assigned value to "addr"
it seems useless.
static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring)
{
unsigned long long addr;
..
..
addr = (unsigned long lo
Do not leak memory by updating pointer with potentially NULL realloc return
value.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/usb/wusbcore/security.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/
Hi Bhupesh,
On Tuesday 07 August 2012 23:07:56 Bhupesh SHARMA wrote:
> On Tuesday, August 07, 2012 8:23 PM Laurent Pinchart wrote:
> > On Tuesday 31 July 2012 06:24:51 Bhupesh Sharma wrote:
> > > This patch reworks the videobuffer management logic present in the
> > > UVC webcam gadget and ports i
Hello Greg, Alan,
In the 3.4 kernel, we have observed that the RNDIS function driver clears
the string id reference to 0 during unbind. And, during bind, we see that
the rndis_init() itself is initiated only when the RNDIS string id reference
is 0. Is this ok?
The issue behind this query is:
As r
From: Michael Grzeschik
This patch fixes an issue introduced by patch:
72c973d usb: gadget: add usb_endpoint_descriptor to struct usb_ep
Without this patch we see a kworker taking 100% CPU, after this sequence:
- Connect gadget to a windows host
- load g_ether
- ifconfig up ; ifconfig down
From: fangxiaozhi
1. This patch is based on the kernel of 3.6-rc1
2. In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices. And at the same time, remove the
redundant declarations from option.c.
Signed-off-by: fangxiaozhi
--
On Wednesday 08 August 2012, Linus Walleij wrote:
> On Wed, Aug 8, 2012 at 3:39 AM, Tony Prisk wrote:
>
> > Converted the existing arch-vt8500 gpio to a platform_device.
> > Added support for WM8505 and WM8650 GPIO controllers.
> (...)
> > +++ b/drivers/gpio/gpio-vt8500.c
>
> This driver looks v
Do not leak memory by updating pointer with potentially
NULL realloc return value.
By the way remove unused local variable:
struct whc_page_list_entry *entry;
More precisely, it was used to increment uninitialized value within one of
cycles.
Found by Linux Driver Verification project (li
On Wed, Aug 8, 2012 at 3:39 AM, Tony Prisk wrote:
> Converted the existing arch-vt8500 gpio to a platform_device.
> Added support for WM8505 and WM8650 GPIO controllers.
(...)
> +++ b/drivers/gpio/gpio-vt8500.c
This driver looks very one-bit-per-gpio typed. Are you sure you cannot
just reuse dri
Calling memory allocation function from the context of interrupt:
request_irq(udc->irq, mv_udc_irq, IRQF_SHARED, driver_name, udc);
Function
mv_udc_irq(..) calls:
irq_process_tr_complete(..) that calls:
handle_setup_packet(..) that calls:
ch9setaddress(..) that calls:
udc_prime_status(..) that call
Hi Oliver,
On 08/08/2012 08:14 AM, Olivier Sobrie wrote:
> Hi Wolfgang,
>
> On Tue, Aug 07, 2012 at 08:26:38AM +0200, Wolfgang Grandegger wrote:
>> On 08/06/2012 07:21 AM, Olivier Sobrie wrote:
>>> This driver provides support for several Kvaser CAN/USB devices.
>>> Such kind of devices supports
Adding usbphy node for Exynos4210 along with the platform data.
Signed-off-by: Praveen Paneri
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos4-dt.c |8
arch/arm/mach-exynos/setup-usb-phy.c
Adding platform device for samsung-usbphy driver. Enabling it for
s3c64xx based machines using s3c-hsotg.
Signed-off-by: Praveen Paneri
---
arch/arm/mach-s3c64xx/include/mach/map.h |2 +
arch/arm/mach-s3c64xx/mach-crag6410.c|4 +++
arch/arm/mach-s3c64xx/mach-smartq.c
This patch removes old phy code from platform side. 'setup-usb-phy.c'
will be used for providing transceiver platform data in next
patch. Not all of the platform data code is removed as there are others
making use of platform_data defined for hsotg. That can be removed once
all the SoCs start using
Adding the transceiver to hsotg driver. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Praveen Paneri
---
drivers/usb/gadget/s3c-hsotg.c | 40 ++--
1 files changed, 30 insertions(+), 10 deletions(-
This driver uses usb_phy interface to interact with s3c-hsotg. Supports
phy_init and phy_shutdown functions to enable/disable phy. Tested with
smdk6410 and smdkv310. More SoCs can be brought under later.
Signed-off-by: Praveen Paneri
Acked-by: Heiko Stuebner
---
.../devicetree/bindings/usb/sams
Changes from v2:
Changed the driver filenames to samsung-usbphy
Changed 's3c' to 'samsung' for platform device as well as platform data
Moved platform data structure to a separate file
Rectified coding style related errors
Changes from v1:
Rebased patches to latest usb-next branch
Changed the name
Le mercredi 8 août 2012 00:56:26 Jesper Juhl, vous avez écrit :
> We allocate memory for 'req' with usb_alloc_urb() and then test
> 'if (!req || rx_submit(pnd, req, GFP_KERNEL | __GFP_COLD))'.
> If we enter that branch due to '!req' then there is no problem. But if
> we enter the branch due to 'req
65 matches
Mail list logo
