On Mon, Jun 9, 2014 at 3:21 PM, Sascha Silbe wrote:
> The chips can operate either in regular or in bitbang mode. Care was
> taken to prevent using GPIOs if the serial device is in use and vice
> versa.
Very interesting patch! I've seen USB-based GPIO things before
but never a dual-mode thing.
> > > > I am just worried if we change the behaviour of using gadget
> > > > driver, can it be accepted by user? If you think it can be
> > > > accepted if we can have some docs, we can implement manually
> > > > binding for gadget driver from now on.
> > >
> > > user shouldn't have to deal with
On Thu, Jun 12, 2014 at 11:34:12PM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> Signed-off-by: Janne Kanniainen
> ---
> Changes in v2:
> - sorted headers to alphabetic order
> - using devm_kzalloc
>
This fixes the following warning:
- WARNING: __constant_cpu_to_le32 should be cpu_to_le32
Signed-off-by: Alexey Tulia
---
drivers/staging/usbip/vhci_hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd
On Mon, Jun 09 2014, wei.y...@windriver.com wrote:
> From: Yang Wei
>
> While loading g_mass_storage module, the following warning
> is triggered.
>
> WARNING: at drivers/usb/gadget/composite.c:
> usb_composite_setup_continue: Unexpected call
> Modules linked in: fat vfat minix nls_cp437 nls_iso88
>
> > > Peter, correct me if this is wrong. It sounds like you want to have
> > > a way for the user to control which gadget driver gets bound to
> > > which UDC driver when everything is compiled into the kernel,
> > > nothing is built as a separate module. Is that the basic idea?
> >
> > Yes
Although you might be nervous about my e-mail as we have not met
before. My name is Mrs Teresa Au, I work with HSBC Hong Kong; there is
a sum of USD$23,200,000.00 business proposal I want to share with you.
It is absolutely risk free; if you are interested send me a reply to
my private e-m
usb_gadget_disconnect() shouldn't be called under spinlock to avoid
spinlock recursion. Function usb_gadget_disconnect() calls pullup(),
which is callback from UDC driver, usually calling composite_disconnect().
This function wants to lock spinlock used in usb_function_deactivate()
causing spinlock
Hi,
On Wed, Jun 11, 2014 at 9:09 PM, Alan Stern wrote:
> On Fri, 6 Jun 2014, Vivek Gautam wrote:
>
>> Facilitate getting required 3.3V and 1.0V VDD supply for
>> EHCI controller on Exynos.
>>
>> With patches for regulators' nodes merged in 3.15:
>> c8c253f ARM: dts: Add regulator entries to smdk
From: Robert Baldyga
> usb_gadget_disconnect() shouldn't be called under spinlock to avoid
> spinlock recursion. Function usb_gadget_disconnect() calls pullup(),
> which is callback from UDC driver, usually calling composite_disconnect().
> This function wants to lock spinlock used in usb_function_
This patch adds the USB xHCI support for the R-Car H2 and M2 SoCs.
These SoCs use an xHCI but still need specific initialization, mainly
to setup the firmware downloading and the specific registers.
This patch set is based on the usb-next branch of Greg usb.git tree.
(commit id = 4a95b1fce97756d03
The R-Car H2 and M2 SoCs come with an xHCI controller that requires
some specific initializations related to the firmware downloading and
some specific registers. This patch adds the support for this special
configuration as an xHCI quirk executed during probe and start.
Signed-off-by: Yoshihiro S
Even though usb_functionfs_descs_head structure is now deprecated,
it has been used by some user space tools. Its removel in commit
[ac8dde1: “Add flags to descriptors block”] was an oversight
leading to build breakage for such tools.
Bring it back so that old user space tools can still be build
Michal Nazarewicz (6):
usb: gadget: f_fs: resurect usb_functionfs_descs_head structure
tools: ffs-test: fix header values endianess
usb: gadget: f_fs: add usb_functionfs_descs_head_v2 structure
tools: ffs-test: convert to new descriptor format
tools: ffs-test: add compatibility code for o
It appears that no one ever run ffs-test on a big-endian machine,
since it used cpu-endianess for fs_count and hs_count fields which
should be in little-endian format. Fix by wrapping the numbers in
cpu_to_le32.
Cc: sta...@vger.kernel.org
Signed-off-by: Michal Nazarewicz
---
tools/usb/ffs-test.
On Fri, 13 Jun 2014, Yang,Wei wrote:
> On 06/09/2014 02:19 PM, wei.y...@windriver.com wrote:
> > From: Yang Wei
> >
> > While loading g_mass_storage module, the following warning
> > is triggered.
> >
> > WARNING: at drivers/usb/gadget/composite.c:
> > usb_composite_setup_continue: Unexpected cal
If ffs-test is used with a kernel prior to 3.14, which do not
support the new descriptors format, it will fail when trying to
write the descriptors. Add a function that converts the new
descriptors to the legacy ones and use it to retry writing the
descriptors using the legacy format.
Also add “-
While loading g_mass_storage module, the following warning can
trigger:
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>]
(d
The structure can be used with user space tools that use the new
functionfs description format, for example as follows:
static const struct {
struct usb_functionfs_descs_head_v2 header;
__le32 fs_count;
__le32 hs_count;
struct {
…
} fs_desc;
Since commit [ac8dde11: “Add flags to descriptors block”] functionfs
supports a new, more powerful and extensible, descriptor format.
Since ffs-test is probably the first thing users of the functionfs
interface see when they start writing functionfs user space daemons,
convert it to use the new for
On Fri, 13 Jun 2014, Michal Nazarewicz wrote:
> > The root cause is that the existing code fails to take into
> > account the possibility that common->new_fsg can change while
> > do_set_interface() is running, because the spinlock isn't held
> > at this point.
>
> common->new_fsg is not protecte
On Fri, 13 Jun 2014, Peter Chen wrote:
> OK, we can keep our g_xxx gadget driver just support the basic feature. But
> the bug that causes gadget driver load fail due to udc is probed deferral
> should
> be fixed, do you think so, we can't wait until configfs has total been ready.
That problem h
On Fri, 13 Jun 2014, Michal Nazarewicz wrote:
> While loading g_mass_storage module, the following warning can
> trigger:
>
> WARNING: at drivers/usb/gadget/composite.c:
> usb_composite_setup_continue: Unexpected call
> Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
> [<
Hi,
On Fri, Jun 13, 2014 at 09:20:31PM +0900, Yoshihiro Shimoda wrote:
> The R-Car H2 and M2 SoCs come with an xHCI controller that requires
> some specific initializations related to the firmware downloading and
> some specific registers. This patch adds the support for this special
> configurati
On Fri, Jun 13 2014, Alan Stern wrote:
> On Fri, 13 Jun 2014, Michal Nazarewicz wrote:
>
>> > The root cause is that the existing code fails to take into
>> > account the possibility that common->new_fsg can change while
>> > do_set_interface() is running, because the spinlock isn't held
>> > at t
> Ok, so you decided to continue setting mode on every LED brightness
> update. That should be fine, but you never answered my question about
> whether it is necessary?
I decided to do it that way because official driver did it as well. I
can check if it is necessary.
> You're almost done. One la
On 13/06/14 15:25, Felipe Balbi wrote:
> Hi,
>
>> + +#define FIRMWARE_NAME "r8a779x_usb3_v1.dlmem"
>> +MODULE_FIRMWARE(FIRMWARE_NAME);
Where can we get this from, it would be nice to test this.
>> +/*** Register Offset ***/ +#define RCAR_USB3_INT_ENA0x224 /*
>> Interrupt
From: Jeff Westfahl
When disconnecting, it's possible that another thread has already made it
into eth_start_xmit before we call netif_stop_queue. This can lead to a
crash as eth_start_xmit tries to use resources that gether_disconnect is
freeing. Use netif_tx_lock/unlock around netif_stop_queue
On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote:
> On Mon, Jun 9, 2014 at 3:21 PM, Sascha Silbe wrote:
>
> > The chips can operate either in regular or in bitbang mode. Care was
> > taken to prevent using GPIOs if the serial device is in use and vice
> > versa.
>
> Very interesting
On Fri, Jun 13, 2014 at 08:30:53AM +0200, Bernhard Cygan wrote:
> lsusb output:
>
> Bus 002 Device 002: ID 8087:8000 Intel Corp.
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 002: ID 8087:8008 Intel Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2
Hi All,
I'm happy to announce the libusb-1.0.19 final release.
The big feature of this release is support for bulk-streams on
Mac OS X and Linux (using the new usbfs API for this from 3.15).
Changelog:
* Add support for USB bulk streams on Linux and Mac OS X (#11)
* Windows: Add AMD and Intel US
Hi Roger,
On Mon, 5 May 2014, Roger Quadros wrote:
> Add the sysconfig class bits for the Super Speed USB
> controllers
>
> CC: Paul Walmsley
> Signed-off-by: Roger Quadros
As with the previous DRA7 hwmod patch, I'd like to get a Reviewed-by: and
a Tested-by: before merging this one.
- Pau
Greetings From Sivia
Dear how are you today? and how is things moving with you? hope fine and you
are in good health.My name is Sivia, I am looking for a very nice
person of love, caring, sincere, easy going, matured, and
understanding, i came across your Email today and decided to be in
touch wit
Forward to USB mail alias for the USB question.
Original post
Subject: Question about USB hotplug
Date: Sat, 14 Jun 2014 09:59:45 +0800
Sender: Simon Guo
Receiver: kernelnewb...@kernelnewbies.org, wei.guo.si...@gmail.com
Hi, dear list,
I want to be clear about the USB hotplug
34 matches
Mail list logo
