On Wed, Jun 04, 2014 at 01:05:03PM -0400, Mike Remski wrote:
> On 06/04/2014 12:00 PM, Johan Hovold wrote:
> > On Wed, Jun 04, 2014 at 11:41:47AM -0400, Mike Remski wrote:
> >> Ok, had a chance to try the cdc-acm; yes it's the ancient one that is
> >> in the base install of CentOS 6.4 (2.6.32-71.2
Commit [ac8dde11: “usb: gadget: f_fs: Add flags to descriptors block”]
which introduced a new descriptor format for FunctionFS removed the
usb_functionfs_descs_head structure, which is still used by ffs-test.
tool.
Convert ffs-test by converting it to use the new header format. For
testing kernel
Even though usb_functionfs_descs_head structure is now deprecated,
it has been used by some user space tools. It's 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
w
W dniu 04.06.2014 17:26, Alan Stern pisze:
On Wed, 4 Jun 2014, Andrzej Pietrasiewicz wrote:
What is the difference in purpose between usb_function and
usb_function_instance? I can't tell just by reading the header file.
Does one of them get created dynamically when the host sets the
approp
[ +CC: linux-usb ]
On Sat, May 31, 2014 at 06:46:44PM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exist in MSI
> GT683R laptop.
>
> Signed-off-by: Janne Kanniainen
> ---
> drivers/leds/Kconfig | 6 ++
> drivers/leds/Makefile | 1 +
Hi,
> -Original Message-
> From: Michal Nazarewicz [mailto:min...@mina86.com]
> Sent: Thursday, June 05, 2014 9:43 AM
> To: Felipe Balbi
> Cc: Krzysztof Opasiak; linux-usb@vger.kernel.org; linux-
> ker...@vger.kernel.org; Michal Nazarewicz
> Subject: [PATCH 2/2] tools: ffs-test: convert to
Hi,
> -Original Message-
> From: Michal Nazarewicz [mailto:m...@google.com] On Behalf Of Michal
> Nazarewicz
> Sent: Wednesday, June 04, 2014 9:06 PM
> To: Krzysztof Opasiak; 'Manu Gautam'
> Cc: ba...@ti.com; ja...@codeaurora.org; pheat...@codeaurora.org;
> linux-usb@vger.kernel.org; linux
On Thu, Jun 05 2014, Krzysztof Opasiak wrote:
> I would suggest adding a suitable structure as you described in
> previous discussion[1]. Writing first 3 fields in each userspace
> program doesn't look quite good. Using:
>
> #ifndef USE_LEGACY_DESC_HEAD
> struct {
> struct usb_functionfs_des
This allows resources such as GPIOs and clocks, which can be
matched based on the device name when requested, to be
assigned even when PLATFORM_DEVID_AUTO is used.
Signed-off-by: Heikki Krogerus
Cc: Greg Kroah-Hartman
---
drivers/base/platform.c | 77 ++--
On some platforms a PHY may need to be handled also in the
host controller driver. Exynos5420 SoC requires some "PHY
tuning" based on the USB speed. This patch delivers dwc3's
PHYs to the xhci platform device when it's created.
Signed-off-by: Heikki Krogerus
Cc: Felipe Balbi
---
drivers/usb/dwc
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-core.c | 45 +++--
drivers/phy/phy-exynos-dp-video.c | 2 +-
drivers/phy/phy-exynos-mipi-v
Provide complete association for the phy and it's user
(musb) with the new phy lookup method.
Signed-off-by: Heikki Krogerus
Cc: Tony Lindgren
---
arch/arm/mach-omap2/twl-common.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-com
Hi,
So the idea with these is that they should help to make it possible to
request phys without caring about how they are mapped to the
consumers, meaning, was is the mapping done in DT, ACPI, etc. Mapping
phys to consumers can be now done with lookups similarly how clocks
can be mapped in clkdev.
This makes to_phy() macro work with other variable names
besides "dev".
Signed-off-by: Heikki Krogerus
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 2760744..10d9714 100644
--- a/include/lin
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from clkdev.c.
Signed-off-by: Heikki Krogerus
---
Documentation/phy.txt | 66 ---
drivers/phy/phy-core.c | 135 +++-
include/l
Hi Heikki,
On Thu, Jun 5, 2014 at 6:22 PM, Heikki Krogerus
wrote:
> Hi,
>
> So the idea with these is that they should help to make it possible to
> request phys without caring about how they are mapped to the
> consumers, meaning, was is the mapping done in DT, ACPI, etc. Mapping
> phys to cons
Commit 1826e9b1 fixes the use after free of "dev".
However if this is not the final call to dev_release()
and the state is not reset to STATE_DEV_DISABLED and
hence all further open() calls to the gadgetfs ep0
device will fail with EBUSY.
So this commit reverts 1826e9b1 and places the call
put_dev
Hi,
> -Original Message-
> From: Michal Nazarewicz [mailto:m...@google.com] On Behalf Of Michal
> Nazarewicz
> Sent: Thursday, June 05, 2014 1:56 PM
> To: Krzysztof Opasiak; 'Felipe Balbi'
> Cc: Krzysztof Opasiak; linux-usb@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [P
Code and comment style clean ups of ftdi_set_max_packet_size().
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 19f1114
Some FTDI devices have broken endpoint descriptors that needs to be
fixed up during probe. Mike Remski discovered that the current
implementation is broken as it crashes the kernel if an interface
without endpoints is probed.
These patches fix this bug, while cleaning up the max-packet-size
handli
Remove redundant mtxorb quirk used to fix up incorrect wMaxPacketSize,
which was added before 895f28badce9 ("USB: ftdi_sio: fix hi-speed device
packet size calculation") which does the same thing for all devices.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 47
Fix NULL-pointer dereference when probing an interface with no
endpoints.
These devices have two bulk endpoints per interface, but this avoids
crashing the kernel if a user forces a non-FTDI device to be probed.
Note that the iterator variable was made unsigned in order to avoid
a maybe-uninitial
There's no need to print the number of endpoints per interface or
endpoint wMaxPacketSize during port probe. This information is readily
available using lsusb should it ever be needed.
Note that this also fixes the wMaxPacketSize being incorrectly reported
on big-endian systems due to a missing le
Promote max-packet-size-override message to warning level and use the
port device for logging, while using actual endpoint numbers in the
message itself.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers
Hello.
On 06/05/2014 11:43 AM, Michal Nazarewicz wrote:
Even though usb_functionfs_descs_head structure is now deprecated,
it has been used by some user space tools. It's removel in commit
s/It's removel/Its removal/.
[ac8dde1: Add flags to descriptors block] was an oversight leading
to
Hello.
On 06/05/2014 05:08 PM, Marcus Nutzinger wrote:
Commit 1826e9b1 fixes the use after free of "dev".
Please also specify that commit's summary line in parens.
However if this is not the final call to dev_release()
and the state is not reset to STATE_DEV_DISABLED and
hence all furthe
2014-06-05 13:06 GMT+02:00:
>> + dev_err(&led->usb_dev->dev, "Message to be send to device is
>> too long\n");
there's a typo: s/send/sent/
--
Daniele Forsi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
On Thu, 5 Jun 2014, Peter Chen wrote:
> > > > It is a little strange we call gadget's disconnect at SET_ADDRESS?
> > > > How the udc calls gadget driver the disconnection has happened when
> > > > the usb cable is disconnected from the host?
> > > >
> > > > Usually, we call gadget's disconnect at
This reverts commit 1826e9b1 (usb: gadget: gadgetfs: use
after free in dev_release()) and places the call to
put_dev() after setting the state.
If this is not the final call to dev_release() and the
state is not reset to STATE_DEV_DISABLED and hence all
further open() calls to the gadgetfs ep0 dev
On Thu, Jun 05, 2014 at 04:05:51PM +0200, Johan Hovold wrote:
> Some FTDI devices have broken endpoint descriptors that needs to be
> fixed up during probe. Mike Remski discovered that the current
> implementation is broken as it crashes the kernel if an interface
> without endpoints is probed.
>
Dell Latitude E6530, BIOS A11, seeing a crash in xhci_add_ep_to_interval
when it's docked in a newer dock that has USB3.
It's very possible that the BIOS is buggy - it isn't like I haven't found
BIOS bugs in every single Dell laptop I've had. :) But that shouldn't
make the kernel crash
lsusb
Hi Sergei,
On Jun 5, 2014, at 4:18 PM, Sergei Shtylyov
wrote:
> Please also specify that commit's summary line in parens.
I'll resubmit the updated patch in a minute!
>> +/* other endpoints were all decoupled from this device */
>> +spin_lock_irq(&dev->lock);
>> +dev->state = ST
On 05/26/2014 08:19 PM, Heinz Diehl wrote:
> On 26.05.2014, Mathias Nyman wrote:
>
>> This would be helpful, I've got a LeCroy protocol analyzer in Finland.
>
>> Heinz, if you're willing to send it to Europe Finland I'll gladly take it,
>> (I'll send the address details in a separate personal m
After commit 4814030ce11f08350b7, the core now sets
hcd->state = HC_STATE_RUNNING in usb_add_hcd() before
the driver's start() method is called.
So, we can safely remove this line from dummy_start()
since it is now superfluous.
Signed-off-by: Pantelis Koukousoulas
---
drivers/usb/gadget/dummy_h
Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q
DMP.
Signed-off-by: Antoine Ténart
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
b/arch/arm/boot/dts/berl
Adds nodes describing the Marvell Berlin BG2Q USB PHY and USB. The BG2Q
SoC has 3 USB host controller, compatible with ChipIdea.
Signed-off-by: Antoine Ténart
---
arch/arm/boot/dts/berlin2q.dtsi | 51 +
1 file changed, 51 insertions(+)
diff --git a/arch/a
The Marvell Berlin USB controllers are compatible with ChipIdea. Add a
driver using the ChipIdea common functions to support them.
Signed-off-by: Antoine Ténart
---
drivers/usb/chipidea/Makefile | 1 +
drivers/usb/chipidea/ci_hdrc_berlin.c | 108 ++
2 fi
Document the bindings of the Marvell Berlin USB PHY driver.
Signed-off-by: Antoine Ténart
---
.../devicetree/bindings/usb/berlin-usbphy.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/berlin-usbphy.txt
diff --git a
Document the Marvell Berlin USB driver bindings.
Signed-off-by: Antoine Ténart
---
.../devicetree/bindings/usb/ci-hdrc-berlin.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-berlin.txt
diff --git a/Documenta
Add the driver driving the Marvell Berlin USB PHY. This allows to
initialize the PHY and to use it from the USB driver later.
Signed-off-by: Antoine Ténart
---
drivers/usb/phy/Kconfig | 9 ++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/phy-berlin-usb.c | 223
This series adds the support for the Marvell Berlin USB controllers,
the USB PHYs and also adds a reset controller.
The reset controller is used by the USB PHY driver and shares the
existing chip controller node with the clocks and one pin controller.
The Marvell Berlin USB controllers are host o
[ adding Mathias ]
On Thu, Jun 5, 2014 at 8:22 AM, Valdis Kletnieks
wrote:
> Dell Latitude E6530, BIOS A11, seeing a crash in xhci_add_ep_to_interval
> when it's docked in a newer dock that has USB3.
>
> It's very possible that the BIOS is buggy - it isn't like I haven't found
> BIOS bugs in ever
On Thu, 5 Jun 2014, Marcus Nutzinger wrote:
> Hi Sergei,
>
> On Jun 5, 2014, at 4:18 PM, Sergei Shtylyov
> wrote:
>
> > Please also specify that commit's summary line in parens.
>
> I'll resubmit the updated patch in a minute!
>
> >> + /* other endpoints were all decoupled from this devic
On Thu, Jun 05, 2014 at 08:30:42AM -0700, Greg KH wrote:
> On Thu, Jun 05, 2014 at 04:05:51PM +0200, Johan Hovold wrote:
> > Some FTDI devices have broken endpoint descriptors that needs to be
> > fixed up during probe. Mike Remski discovered that the current
> > implementation is broken as it cras
On Thu, 2014-06-05 at 16:05 +0200, Johan Hovold wrote:
> Fix NULL-pointer dereference when probing an interface with no
> endpoints.
>
> These devices have two bulk endpoints per interface, but this avoids
> crashing the kernel if a user forces a non-FTDI device to be probed.
>
> Note that the it
On Thu, Jun 05, 2014 at 05:13:49PM +0100, Ben Hutchings wrote:
> On Thu, 2014-06-05 at 16:05 +0200, Johan Hovold wrote:
> > Fix NULL-pointer dereference when probing an interface with no
> > endpoints.
> >
> > These devices have two bulk endpoints per interface, but this avoids
> > crashing the ke
On Thu, Jun 05, 2014 at 06:04:32PM +0200, Johan Hovold wrote:
> On Thu, Jun 05, 2014 at 08:30:42AM -0700, Greg KH wrote:
> > On Thu, Jun 05, 2014 at 04:05:51PM +0200, Johan Hovold wrote:
> > > Some FTDI devices have broken endpoint descriptors that needs to be
> > > fixed up during probe. Mike Rems
On Thu, 05 Jun 2014 08:55:07 -0700, Dan Williams said:
> > On a working boot, it progresses:
>
> Is a working boot after reverting that change, or it intermittently
> works? If it's the latter I'm not sure I trust the bisect result,
> yet.
Oh, it's a 100% guaranteed crash. The following is from
On Thu, Jun 5, 2014 at 9:24 AM, wrote:
> On Thu, 05 Jun 2014 08:55:07 -0700, Dan Williams said:
>
>> > On a working boot, it progresses:
>>
>> Is a working boot after reverting that change, or it intermittently
>> works? If it's the latter I'm not sure I trust the bisect result,
>> yet.
>
> Oh,
On Thu, 05 Jun 2014 09:35:48 -0700, Dan Williams said:
> Actually, on second look I bet xhci_alloc_tt_info() is being called
> while hdev->maxchild is not set. Let me throw together a debug
> patch...
Sure, no problem - just let me know what variant of linux-next you
want it applied against. :)
On Wed, 4 Jun 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_iso885
On Thu, 5 Jun 2014, Andrzej Pietrasiewicz wrote:
> I think it is easier to tell the purpose of the two structures taking
> gadgets composed with configfs as example.
>
> In each gadget there is "functions" directory. Function directories
> are created there:
>
> $ cd $CONFIGFS_ROOT/usb_gadget/ou
Hello.
On 06/05/2014 07:44 PM, Pantelis Koukousoulas wrote:
After commit 4814030ce11f08350b7, the core now sets
Please also specify that commit's summary line in parens.
hcd->state = HC_STATE_RUNNING in usb_add_hcd() before
the driver's start() method is called.
So, we can safely remo
On Thu, Jun 5, 2014 at 9:13 PM, Sergei Shtylyov
wrote:
>> After commit 4814030ce11f08350b7, the core now sets
>
>Please also specify that commit's summary line in parens.
Is this in order to be able to grep it more easily? I 'm asking because
that summary (Initialize hcd->state roothubs) does
On Thu, 2014-06-05 at 13:29 -0400, valdis.kletni...@vt.edu wrote:
> On Thu, 05 Jun 2014 09:35:48 -0700, Dan Williams said:
>
> > Actually, on second look I bet xhci_alloc_tt_info() is being called
> > while hdev->maxchild is not set. Let me throw together a debug
> > patch...
>
> Sure, no proble
The quirks_param array is located in the BSS, no need to explicitly
initialize it with NULL.
Signed-off-by: Mathias Krause
---
drivers/hid/usbhid/hid-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index
Hello.
On 06/05/2014 10:55 PM, Pantelis Koukousoulas wrote:
After commit 4814030ce11f08350b7, the core now sets
Please also specify that commit's summary line in parens.
Is this in order to be able to grep it more easily? I 'm asking because
It's actually the only way to uniquely
After commit 4814030ce11f08350b7,
(usb: initialize hcd->state roothubs)
the core now sets hcd->state = HC_STATE_RUNNING in
usb_add_hcd() before the driver's start() method is called.
So, we can safely remove this line from dummy_start()
since it is now superfluous.
Signed-off-by: Pantelis Koukou
Hi Greg,
Here are a couple of simple fixes from my backlog of ARM
randconfig bugs. Nothing urgent, they can probably all go
into next for 3.17 after the merge window, but see for
yourself.
Arnd
Arnd Bergmann (5):
staging: lirc: remove sa1100 support
staging/iio: IIO_SIMPLE_DUMMY_BUFF
If the USB code is a loadable module, this driver cannot
be built-in. This adds an explicit dependency on CONFIG_USB
so that Kconfig can force sn9c102 to be a module in this case.
Signed-off-by: Arnd Bergmann
Cc: Luca Risolia
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
Cc: linux-u
ng of hdev->maxchild.
>
> Cc: Mathias Nyman
> Reported-by: Valdis Kletnieks
> Signed-off-by: Dan Williams
Applied cleanly, booted without complaint, the keyboard that's behind
the PS2-USB converter works.
uname -r reports 3.15.0-rc8-next-20140605-dirty as expected.
So fee
; hdev->maxchild already being set. Do the minimal fix and move it after
>> the setting of hdev->maxchild.
>>
>> Cc: Mathias Nyman
>> Reported-by: Valdis Kletnieks
>> Signed-off-by: Dan Williams
>
> Applied cleanly, booted without complaint, the keyboard th
Commit d8521afe3586 "usb: assign default peer ports for root hubs"
delayed marking a hub valid (set hdev->maxchild) until it had been fully
configured and to enable the publishing of valid hubs to be serialized
by usb_port_peer_mutex.
However, xhci_update_hub_device() in some cases depends on
hdev
Hi Mathias, hit a small issue playing with -next:
On Thu, May 8, 2014 at 9:26 AM, Mathias Nyman
wrote:
> To create a global command queue we require that each command put on the
> command ring is submitted with a command structure.
>
> Functions that queue commands and wait for completion need to
+ Kishon.
Hi,
On Thu, Jun 5, 2014 at 9:18 PM, Antoine Ténart
wrote:
> Add the driver driving the Marvell Berlin USB PHY. This allows to
> initialize the PHY and to use it from the USB driver later.
Just out of curiosity, going forward we would like to have phy drivers based on
generic phy fram
65 matches
Mail list logo
