On Mon, Jul 06, 2015 at 03:24:17PM +0200, Peter Stuge wrote:
> Unrelated, but I also have some ch341 hardware, and mine does not
> work with the mainline driver, it does however work reliably with the
> vendor driver.
>
> The two drivers initialize the hardware fairly differently,
> especially th
Hi Shimoda-san,
On 06 July 2015 08:18, Shimoda-san wrote:
> Hi Phil-san,
>
> Thank you very much for the patch!
>
> > Sent: Thursday, July 02, 2015 5:06 PM
> < snip >
> > +/* VBUS change IRQ handler */
> > +static irqreturn_t gpio_vbus_irq(int irq, void *data)
> > +{
> > + struct rcar_gen2_cha
Hi Shimoda-san,
On 06 July 2015 08:28, Shimoda-san wrote:
> Hi Phil-san,
>
> > Sent: Thursday, July 02, 2015 7:27 PM
> >
> > These changes allow a PHY driver to trigger a VBUS interrupt and
> > to provide the value of VBUS.
> >
> > Signed-off-by: Phil Edworthy
>
> Thank you for the patch!
>
>
Hi Laurent,
On 06 July 2015 09:20, Laurent wrote:
> Hi Phil,
>
> Thank you for the patch.
Thanks for your review!
> On Thursday 02 July 2015 11:26:33 Phil Edworthy wrote:
> > These changes allow a PHY driver to trigger a VBUS interrupt and
> > to provide the value of VBUS.
> >
> > Signed-off-by
Sorry for misunderstanding, I've tested the behavior of Arduino board
on 2 machines and the result is following:
PASSED - Arduino board was connected successfully
FAILED - ch341 errors arose
1st machine [USB 3.0] -- Linux 3.18 -- PASSED
1st machine [USB 3.0] -- Linux 4.* -- FAILED
2nd machine [U
Sorry for misunderstanding, I've tested the behavior of Arduino board
on 2 machines and the result is following:
PASSED - Arduino board connected successfully
FAILED - ch341 errors arose
1st machine [USB 3.0] -- Linux 3.18 -- PASSED
1st machine [USB 3.0] -- Linux 4.* -- FAILED
2nd machine [USB 2
There is a race condition between finish_unlinks->finish_urb()
function and usb_kill_urb() in ohci controller case.
finish_urb is called after calling spin_unlock(&ohci->lock),
then if during this time, usb_kill_urb is called for another
endpoint, then new ed will be added to ed_rm_list at beg
[ Please try to avoid top-posting. ]
On Tue, Jul 07, 2015 at 01:26:33PM +0300, Evgen Druzhynin wrote:
> Sorry for misunderstanding, I've tested the behavior of Arduino board
> on 2 machines and the result is following:
>
> PASSED - Arduino board was connected successfully
> FAILED - ch341 errors
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johan Hovold wrote:
> On Mon, Jul 06, 2015 at 03:24:17PM +0200, Peter Stuge wrote:
>
> > Unrelated, but I also have some ch341 hardware, and mine does not
> > work with the mainline driver, it does however work reliably with the
> > vendor driver.
>
2015-07-07 14:06 GMT+03:00 Johan Hovold :
> Ok, so it looks like a regression between 3.18 and 4.0.
>
> Could you try v3.19 and then run a bisect on either v3.18..v3.19 or
> v3.19..v4.0 depending on the result?
>
> Please verify that v3.18 works and v4.0 fails. Specifically, do not use
> stable rel
There is a race condition between finish_unlinks->finish_urb()
function and usb_kill_urb() in ohci controller case.
The finish_urb is called after calling spin_unlock(&ohci->lock),
then if during this time, usb_kill_urb is called for another
endpoint, then new ed will be added to ed_rm_list at
These changes allow a PHY driver to trigger a VBUS interrupt and
to provide the value of VBUS.
Signed-off-by: Phil Edworthy
---
v5:
- Avoid race when vbus_is_indirect may or may not be read
before the phy has called vbus_session. In doing so, the
changes have also been isolated to mod_
Instead of statically selecting the PHY connection to either the
USBHS (Function) or PCI0 (Host) IP blocks, this change allows the
dts to specifiy gpio pins for the vbus and id signals. Additional
gpio pins are used to control power to an external OTG device and
an override to turn vbus on/off.
No
Both USB Host (pci0) and Function (USBHS) drivers are enabled.
The USB PHY driver determines which IP block should be connected
based on vbus and id signals read via gpios.
Note that switch SW5 and SW6 on Koelsch board needs to be set to
position 3 for this to work.
Signed-off-by: Phil Edworthy
On Mon, 2015-07-06 at 17:46 +0300, Roger Quadros wrote:
>
> -static int find_cable_index_by_name(struct extcon_dev *edev, const char
> *name)
> +static int find_cable_id_by_name(struct extcon_dev *edev, const char *name)
> {
> - unsigned int id = EXTCON_NONE;
> + unsigned int id =
Hi,
On 07/07/15 15:40, Ivan T. Ivanov wrote:
On Mon, 2015-07-06 at 17:46 +0300, Roger Quadros wrote:
-static int find_cable_index_by_name(struct extcon_dev *edev, const char *name)
+static int find_cable_id_by_name(struct extcon_dev *edev, const char *name)
{
- unsigned int id = EXTC
Users of find_cable_index_by_name() will cause a kernel hang
as the while loop counter is never incremented and end condition
is never reached.
extcon_get_cable_state() and extcon_set_cable_state() are broken
because they use cable index instead of cable id. This causes
the first cable state (cabl
Hi,
On 29/06/15 10:47, Li Jun wrote:
Check property of usb hardware to update otg version and disable SRP, HNP
and ADP if its disable flag is present.
Signed-off-by: Li Jun
---
drivers/usb/common/common.c | 47 +
include/linux/usb/of.h | 7 +
On 29/06/15 10:47, Li Jun wrote:
Init and update otg capabilities by DT, set gadget's otg capabilities
accordingly.
Signed-off-by: Li Jun
---
drivers/usb/chipidea/core.c | 10 ++
drivers/usb/chipidea/udc.c | 7 ++-
include/linux/usb/chipidea.h | 1 +
3 files changed, 17 in
On 29/06/15 10:48, Li Jun wrote:
Allocate and initialize usb otg descriptor according to gadget otg
capabilities, add it for each usb configurations. If otg capability
is not defined, keep its original otg descriptor unchanged.
Signed-off-by: Li Jun
---
drivers/usb/gadget/legacy/printer.c | 2
On 29/06/15 10:47, Li Jun wrote:
Allocate and initialize usb otg descriptor according to gadget otg
capabilities, add it for each usb configurations, free it while
ether unbind. If otg capability is not defined, keep its otg
descriptor unchanged.
Signed-off-by: Li Jun
For patches 12 to 20
Re
On 29/06/15 10:48, Li Jun wrote:
Allocate and initialize usb otg descriptor according to gadget otg
capabilities, add it for each usb configurations. If otg capability
is not defined, keep its original otg descriptor unchanged.
Signed-off-by: Li Jun
---
drivers/usb/gadget/legacy/zero.c | 32
On 29/06/15 10:48, Li Jun wrote:
Allocate and initialize usb otg descriptor according to gadget otg
capabilities, add it for each usb configurations. If otg capability
is not defined, keep its original otg descriptor unchanged.
Signed-off-by: Li Jun
---
drivers/usb/gadget/legacy/serial.c |
Hello,
This patch set contains few small bugfixes found in usb gadget functions
and UDC drivers. The most important is the [1] as it fixes bug causing
BUG_ON() in f_fs driver. Remaining patches contain minor fixes.
Best regards,
Robert Baldyga
[1] usb: gadget: ffs: call functionfs_unbind() if _f
Function ffs_do_functionfs_bind() calls functionfs_bind() which allocates
usb request and increments refcounts. These things needs to be cleaned
up by if further steps of initialization fail by calling functionfs_unbind().
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/function/f_fs.c | 10
On Tue, 2015-07-07 at 16:06 +0300, Roger Quadros wrote:
> Users of find_cable_index_by_name() will cause a kernel hang
> as the while loop counter is never incremented and end condition
> is never reached.
>
> extcon_get_cable_state() and extcon_set_cable_state() are broken
> because they use cab
Should use usb_ep_set_maxpacket_limit instead of setting
maxpacket value manually.
Signed-off-by: Robert Baldyga
---
drivers/usb/isp1760/isp1760-udc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/isp1760/isp1760-udc.c
b/drivers/usb/isp1760/isp1760-udc.c
in
Function midi registers two interfaces with single set_alt() function
which means that f_midi_set_alt() is called twice when configuration
is set. That means that endpoint initialization and ep request allocation
is done two times. To avoid this problem we do such things only once,
for interface nu
Should use usb_ep_set_maxpacket_limit instead of setting
maxpacket value manually.
Signed-off-by: Robert Baldyga
---
drivers/staging/emxx_udc/emxx_udc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.
Add missing return value check. In case of error print debug message
and return error code.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_us
Hello.
On 7/7/2015 5:02 PM, Robert Baldyga wrote:
Should use usb_ep_set_maxpacket_limit instead of setting
maxpacket value manually.
Signed-off-by: Robert Baldyga
---
drivers/staging/emxx_udc/emxx_udc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/stagi
On Mon, 6 Jul 2015, Felipe Balbi wrote:
> > You know, this is the first time I've run across this optimization.
> >
> > In principle it applies to any USB host controller, not just to PHYs.
> > There's no reason to enable wakeup for a controller if none of the
> > attached devices can issue a
On Tue, Jul 07, 2015 at 04:02:49PM +0200, Robert Baldyga wrote:
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index 6e7be91..966b214 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -2897,11 +2897,19 @@
Hello,
This series fix a few bugs in mass storage function, adds a warning
message when binding function with not contiguous LUN ids and replace
dynamically allocated luns array with static one what simplifies the
code.
This series also fix GET_MAX_LUNS request to return max id of valid
lun, not
Mass storage spec allows up to 16 LUNs, so let's don't
add some more restrictive limits.
Signed-off-by: Krzysztof Opasiak
Acked-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_mass_storage.c |2 +-
drivers/usb/gadget/function/storage_common.h |2 +-
2 files changed, 2 insertions
EXPORT_SYMBOL_GPL() is usually placed after function definition
not before.
Signed-off-by: Krzysztof Opasiak
Acked-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_mass_storage.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_mass_sto
Creation of LUN 0 may fail (for example due to ENOMEM).
As fsg_common_set_num_buffers() does some memory allocation
we should free it before it becomes unavailable.
Signed-off-by: Krzysztof Opasiak
Acked-by: Michal Nazarewicz
CC: sta...@vger.kernel.org # 3.13+
---
drivers/usb/gadget/function/f_
According to mass storage specification:
"Logical Unit Numbers on the device shall be numbered contiguously
starting from LUN 0 to a maximum LUN of 15 (Fh)"
So let's at least print a warning message that LUNs ids should be
contiguous.
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/fu
This patch replace dynamicly allocated luns array with static one.
This simplifies the code of mass storage function and modules.
It also fix issue with reporting wrong number of LUNs in GET_MAX_LUN
request. According to MS spec we should return the max index of valid
LUN, not the number of luns -
On Tue, Jul 07, 2015 at 04:02:52PM +0200, Robert Baldyga wrote:
> Should use usb_ep_set_maxpacket_limit instead of setting
> maxpacket value manually.
>
Same question.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majo
On Tue, Jul 07, 2015 at 04:02:51PM +0200, Robert Baldyga wrote:
> Should use usb_ep_set_maxpacket_limit instead of setting
> maxpacket value manually.
>
This is a behavior change, right, since now we're setting
ep->ep.maxpacket and ep->ep.maxpacket_limit where before we only set
the first. I don
When the request actual state is equal to lenght, besides setting the
request status to done, the status variable also need to be updated.
If not, the status will be EINPROGRESS and the transfer will never be
set as completed.
Signed-off-by: Rui Miguel Silva
---
drivers/usb/gadget/udc/dummy_hcd.
When processing urb list in dummy_timer and an ep goes away, the urb
is giveback with an -EPROTO error. However the same urb can be
enqueued once again and the loop in dummy_timer never get out.
To fix that, make sure the dummy_hcd is enabled at enqueue time to
avoid adding urb to the urbp list.
On 07/07/2015 04:53 PM, Dan Carpenter wrote:
On Tue, Jul 07, 2015 at 04:02:49PM +0200, Robert Baldyga wrote:
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 6e7be91..966b214 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/funct
On 07/07/2015 05:01 PM, Dan Carpenter wrote:
On Tue, Jul 07, 2015 at 04:02:51PM +0200, Robert Baldyga wrote:
Should use usb_ep_set_maxpacket_limit instead of setting
maxpacket value manually.
This is a behavior change, right, since now we're setting
ep->ep.maxpacket and ep->ep.maxpacket_limit
>>
>> Well, the checkpatch.pl reports were all style (and mostly whitespace);
>> roughly 3000 of them against 3000 lines of code :-/. I did review the
>> code, looking for areas where I thought it would badly cram into the
>> kernel, and I adjusted the few I found (and sent changes upstream).
>
Hi Greg,
Here's the first pull request for this -rc cycle, patches have
been tested on platforms I have access to.
Let me know if you want anything to be changed.
cheers
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
ar
Is this the second version of this patch? If it is, you should say so
in the subject line. For example:
Subject: [PATCH v.2] USB: OHCI: ...
On Tue, 7 Jul 2015, AMAN DEEP wrote:
> There is a race condition between finish_unlinks->finish_urb()
> function and usb_kill_urb() in ohci cont
Hi,
On Tue, Jul 07, 2015 at 04:24:20PM +0100, Rui Miguel Silva wrote:
> When the request actual state is equal to lenght, besides setting the
> request status to done, the status variable also need to be updated.
> If not, the status will be EINPROGRESS and the transfer will never be
> set as comp
Hi,
On Tue, Jul 07, 2015 at 04:25:00PM +0100, Rui Miguel Silva wrote:
> When processing urb list in dummy_timer and an ep goes away, the urb
> is giveback with an -EPROTO error. However the same urb can be
> enqueued once again and the loop in dummy_timer never get out.
>
> To fix that, make sure
On Tue, 7 Jul 2015, Rui Miguel Silva wrote:
> When the request actual state is equal to lenght, besides setting the
"state"? Do you mean "status"?
"lenght" is a typo.
> request status to done, the status variable also need to be updated.
> If not, the status will be EINPROGRESS and the transfe
On Tue, 7 Jul 2015, Rui Miguel Silva wrote:
> When processing urb list in dummy_timer and an ep goes away, the urb
> is giveback with an -EPROTO error. However the same urb can be
> enqueued once again and the loop in dummy_timer never get out.
I don't understand. Why would dummy_timer behave di
On 06/11/2015 10:57 PM, Hauke Mehrtens wrote:
> These patches are fixing minor bugs and are adding support for ARM
> based Broadcom BCM47XX and BCM53XX SoCs.
>
> Changes since:
> v2:
> * split the ARM init function up and change the order to match the
>Broadcom vendor code
> * enable the GP
When a SoC supports both PHY interfaces but
doesn't define HSPHY in DT/pdata, we will get
an unnecessary dev_warn() which can mislead users
into thinking that they're missing something.
Instead, let's just silently rely on a correct
default. If the HW default is wrong, then HSPHY
is required and U
Hi Oliver, hello to who is reading this message.
i was re-reading the code and the oops, without understanding what's the
problem. Still: what impressed me is the fact that at some point you see NULL
ptr dereference in unrelated code (fbcon). Is it possible that at some point
the memory portio
On Tue, Jul 07, 2015 at 12:30:22PM -0500, Felipe Balbi wrote:
> Hi Greg,
>
> Here's the first pull request for this -rc cycle, patches have
> been tested on platforms I have access to.
>
> Let me know if you want anything to be changed.
>
> cheers
>
> The following changes since commit d770e558
Hello.
On 07/07/2015 05:57 PM, Krzysztof Opasiak wrote:
Mass storage spec allows up to 16 LUNs, so let's don't
s/don't/not/.
add some more restrictive limits.
Signed-off-by: Krzysztof Opasiak
Acked-by: Michal Nazarewicz
[...]
WBR, Sergei
--
To unsubscribe from this list: send th
Hi Phil,
Thank you for the patch.
On Tuesday 07 July 2015 12:52:43 Phil Edworthy wrote:
> These changes allow a PHY driver to trigger a VBUS interrupt and
> to provide the value of VBUS.
>
> Signed-off-by: Phil Edworthy
This looks much better to me. I just have two comments, please see below.
> Doug, how would you feel about reworking the patch that exports
> usb_wakeup_enabled_descendants()? Instead of doing it that way, create
> and export a new subroutine in hcd.c called
> usb_hcd_wakeup_not_needed(), or something similar.
We have a use case with another host controller (Tegra, whi
Before I submit a full-blown bug report, could anyone tell me whether
there are already known issues with the xHCI driver on AMD and/or
ASUSTek systems, specifically involving AMD APU chipsets?
I have two different AMD systems, both using ASUSTek AMD motherboards:
an A88XM-E (AMD A88X / Bolton D4
On Tue, Jul 07, 2015 at 04:23:14PM +0300, Roger Quadros wrote:
> Hi,
>
> On 29/06/15 10:47, Li Jun wrote:
> >Check property of usb hardware to update otg version and disable SRP, HNP
> >and ADP if its disable flag is present.
> >
> >Signed-off-by: Li Jun
> >---
> > drivers/usb/common/common.c |
On Tue, Jul 07, 2015 at 04:25:44PM +0300, Roger Quadros wrote:
> On 29/06/15 10:47, Li Jun wrote:
> >Init and update otg capabilities by DT, set gadget's otg capabilities
> >accordingly.
> >
> >Signed-off-by: Li Jun
> >---
> > drivers/usb/chipidea/core.c | 10 ++
> > drivers/usb/chipidea
>Is this the second version of this patch? If it is, you should say so
>in the subject line. For example:
>
>Subject: [PATCH v.2] USB: OHCI: ...
I will take care of this in future.
>> There is a race condition between finish_unlinks->finish_urb()
>> function and usb_kill_urb() in ohci controll
On Tue, Jul 07, 2015 at 04:55:16PM +0300, Roger Quadros wrote:
>
> On 29/06/15 10:48, Li Jun wrote:
> >Allocate and initialize usb otg descriptor according to gadget otg
> >capabilities, add it for each usb configurations. If otg capability
> >is not defined, keep its original otg descriptor uncha
64 matches
Mail list logo
