On 22.04.2012 17:52, Thomas Knauth wrote:
> I am trying to develop a driver for the net2280 successor (USB 3380
> from PLX)...
What is the current state of this project? Is anyone still working on a driver
for the PLX USB3380?
For registered users PLXTech itself offers a driver download[1] which
On Di, 2013-09-17 at 13:30 -0700, Christoph Hellwig wrote:
> On Fri, Sep 13, 2013 at 01:27:12PM +0200, Gerd Hoffmann wrote:
> > Simplifies locking, we'll protect the list with the device spin lock.
> > Also plugs races which can happen when two devices operate on the
> > global list.
> >
> > While
On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > > > On Tuesday 17 September 2013 17:48:59 you
On Wed, Sep 18, 2013 at 10:20 AM, Pali Rohár wrote:
> On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
>> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
>> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
>> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohá
On Tue 2013-09-17 20:45:39, Felipe Balbi wrote:
> On Wed, Sep 18, 2013 at 12:04:27AM +0200, Pavel Machek wrote:
> > On Tue 2013-09-17 10:42:30, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Mon, Sep 02, 2013 at 03:58:32PM +0200, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > checkpatch.pl has som
Hello,
This is a second version of set of patches fixing s3c-hsotg USB driver
functioning. I've fixed issuses pointed by Felipe Balbi. For more information,
please check the change log at the end of the mail.
These patches add few fixes:
- Fix "protocol stall" handling, by enqueue new ep0 request
All requests for endpoint are completed when it was halted and the halt was
cleared by CLEAR_FEATURE, but not when new state is same as previous.
Signed-off-by: Robert Baldyga
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/s3c-hsotg.c | 10 +-
1 file changed, 9 insertions(+), 1 d
After normal handling of SetupDone interrupt, XferCompl interrupt occurs, and
then we enqueue new setup request. But when ep0 is stalled, there is no
XferCompl, so we have to enqueue setup request immediately after stalling ep.
Otherwise incoming control requests won't be processed correctly.
Sign
When s3c_hsotg_trytx is called for ep without enqueued request, interrupts
for this ep are disabled, to prevent interrupt flooding. Interrupts are
enabled when new request for this ep is starting.
Signed-off-by: Robert Baldyga
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/s3c-hsotg.c |
In OEPInt/IEPInt interrupts handling added bitwise and of DAINT and
DAINTMSK, because we should handle masked interrupts only.
Signed-off-by: Robert Baldyga
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/s3c-hsotg.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --g
In s3c_hsotg_write_fifo function PTxFEmp/NPTxFEmp interrupts are enabled
only in shared-fifo mode. In dedicated-fifo mode they should not be used
(when enabled then cause interrupt storm).
Signed-off-by: Robert Baldyga
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/s3c-hsotg.c | 16 +
Property "halted" of s3c_hsotg_ep structure is actually initialised when ep
enabled, and changed when halt is set/cleared.
Signed-off-by: Robert Baldyga
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/s3c-hsotg.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/s
Split otghs_ctrl and USB2 PHY power-down into separate
omap-control-usb nodes. Get rid of "ti,type" property.
Also get rid of "ti,has-mailbox" property from usb_otg_hs
node and provide the ctrl-module phandle.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi |
Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Get rid of "ti,type" property.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.
"usb_otg_ss_refclk960m" is an optional functional clock to the
UBS_OTG_SS module. So manage it in the driver.
Also update device tree binding information.
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/usb/omap-usb.txt |4
drivers/usb/dwc3/dwc3-omap.c
Hi,
This patchset does the following:
* Get rid of omap_control_usb platform data as we support DT only.
* Restructure and add support for new PHY types. We now support the follwing
four types
TYPE_OTGHS - if it has otghs_control mailbox register (e.g. on OMAP4)
TYPE_USB2 - if it has Power do
The OTG_SS controller driver manages the OTG_SS clock. The phy driver
needs to manage the PHY's functional clock. So correct the clock name.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-usb2.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/ph
Add support for new device types and in the process rid of "ti,type"
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types OTGHS, USB2, PIPE3 (e.g. USB3) and DRA7U
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is
omap-control device is present from OMAP4 onwards which
support device tree boots only. So get rid of platform data.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-control.c | 12 +++-
include/linux/usb/omap_control_usb.h |4
2 files changed, 3 insertions(+), 13 d
This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-control.c | 31 ++-
include/linu
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
Also get rid of "ti,has-mailbox" property as it is redundant and
we can dete
Hi!
> >> > So will you do that? Or it is needed to resend this one line
> >> > hunk again in new email again?
> >>
> >> new patch, new email
> >
> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >
> > Sorry but, need to copy full isolated patch/hunk from one mail to
> > another is hassling. So what
On Tue, 2013-09-17 at 17:10 +0800, Ming Lei wrote:
> Commit 638c5115a7949(USBNET: support DMA SG) introduces DMA SG
> if the usb host controller is capable of building packet from
> discontinuous buffers, but missed handling padding packet when
> building DMA SG.
>
> This patch attachs the pre-all
Hi,
On 09/17/2013 08:25 PM, Frank Dierich wrote:
On 09/09/2013 02:09 PM, Hans de Goede wrote:
Thanks for the bug report, looking at the bug reports, they all report an error
of -71 which is
EPROTO, which typically means something is wrong at the USB level.
And nothing has changed for the driv
On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek wrote:
> Hi!
>
>> >> > So will you do that? Or it is needed to resend this one line
>> >> > hunk again in new email again?
>> >>
>> >> new patch, new email
>> >
>> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >
>> > Sorry but, need to copy full isola
Ming Lei writes:
> Commit 638c5115a7949(USBNET: support DMA SG) introduces DMA SG
> if the usb host controller is capable of building packet from
> discontinuous buffers, but missed handling padding packet when
> building DMA SG.
>
> This patch attachs the pre-allocated padding packet at the
> en
Hi,
On Wed, Sep 18, 2013 at 11:20:27AM +0200, Pavel Machek wrote:
> On Tue 2013-09-17 20:45:39, Felipe Balbi wrote:
> > On Wed, Sep 18, 2013 at 12:04:27AM +0200, Pavel Machek wrote:
> > > On Tue 2013-09-17 10:42:30, Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Mon, Sep 02, 2013 at 03:58:32P
On Wed, Aug 07, 2013 at 05:18:13AM +0800, Peter Chen wrote:
> In order to increase test coverage, we can change the interval between
> two remote wakeups every time, and the interval can be any user defined
> value. This change will no affect current behavior if the user does not
> use two introduc
Hi!
> >> >> > So will you do that? Or it is needed to resend this one line
> >> >> > hunk again in new email again?
> >> >>
> >> >> new patch, new email
> >> >
> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >> >
> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
> >> > an
Hi,
On Wed, Aug 28, 2013 at 05:01:51PM +0100, Mark Rutland wrote:
> > > So it's not physically possible for someone to just wire up a single phy
> > > to the device, either USB2-only or USB3?
> >
> > of course it is :-) In fact, TI has done it. But it causes a whole bunch
> > of other problems to
Hi!
> > gave feedback. If the sender doesn't want to take his feedback into
> > account and prefer to send pretty insulting emails instead that is his
> > choice but I would say that is this not the greatest approach to get
> > your code merged (to say the least).
>
> Clearly not. But Pali found
On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek wrote:
> Hi!
>
>> >> >> > So will you do that? Or it is needed to resend this one line
>> >> >> > hunk again in new email again?
>> >> >>
>> >> >> new patch, new email
>> >> >
>> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >> >
>> >> > Sorry but,
On Wed, Sep 18, 2013 at 9:59 PM, Bjørn Mork wrote:
> Ming Lei writes:
>
>> Commit 638c5115a7949(USBNET: support DMA SG) introduces DMA SG
>> if the usb host controller is capable of building packet from
>> discontinuous buffers, but missed handling padding packet when
>> building DMA SG.
>>
>> Th
> I also believe it would be nice to move the initialisation of can_dma_sg
> away from the minidriver and into usbnet_probe. It's confusing that
> this field is used "uninitialized" (well, defaulting to zero) in all but
> one minidriver. It would much nicer if the logic was more like
>
> usbnet_
On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas
wrote:
> to split the patch in two since the patch was solving
> two separate issues
My patch does not solving *two* issues. It is *one* regression
and both parts of patch are needed for fixing it. Read commit
message again. It do
From: Bjørn Mork
Date: Wed, 18 Sep 2013 17:52:42 +0200
> Ming Lei writes:
>
>> There is no reason to forbid DMA SG for one driver which requires
>> padding, right?
>
> Yes there is: Added complexity for everybody, based on a combination of
> features which just does not make any sense.
>
> No
Hi,
On Wed, Sep 18, 2013 at 04:35:37PM +0200, Pavel Machek wrote:
> Hi!
>
> > > gave feedback. If the sender doesn't want to take his feedback into
> > > account and prefer to send pretty insulting emails instead that is his
> > > choice but I would say that is this not the greatest approach to g
Ming Lei writes:
>> Are you really sure that the one driver/device using this really need
>> the padding byte? If you could just make FLAG_SEND_ZLP part of the
>> condition for enabling can_dma_sg, then all this extra complexity would
>> be unnecessary. As the comment in front of the padding co
On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas
> wrote:
> > to split the patch in two since the patch was solving
> > two separate issues
>
> My patch does not solving *two* issues. It is *one* regression
> and both
On Wed, Sep 18, 2013 at 03:21:18PM +0100, Felipe Balbi wrote:
> Hi,
>
> On Wed, Aug 28, 2013 at 05:01:51PM +0100, Mark Rutland wrote:
> > > > So it's not physically possible for someone to just wire up a single phy
> > > > to the device, either USB2-only or USB3?
> > >
> > > of course it is :-) I
On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > Canillas
> >
> > wrote:
> > > to split the patch in two since the patch was solving
> > > two separate issues
>
Hi,
On Mon, Aug 12, 2013 at 04:05:10PM +0200, Andreas Larsson wrote:
> diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
> new file mode 100644
> index 000..37a6c08
> --- /dev/null
> +++ b/drivers/usb/gadget/gr_udc.c
> @@ -0,0 +1,2268 @@
> +/*
> + * USB Peripheral Controll
On Wed, Sep 18, 2013 at 09:31:55AM +0200, Steffen Sledz wrote:
> On 22.04.2012 17:52, Thomas Knauth wrote:
> > I am trying to develop a driver for the net2280 successor (USB 3380
> > from PLX)...
>
> What is the current state of this project? Is anyone still working on a
> driver for the PLX USB3
On Wed, Sep 18, 2013 at 11:52 PM, Bjørn Mork wrote:
> Ming Lei writes:
>
>>> Are you really sure that the one driver/device using this really need
>>> the padding byte? If you could just make FLAG_SEND_ZLP part of the
>>> condition for enabling can_dma_sg, then all this extra complexity would
>>
&twl->phy.notifier is not initalized
Signed-off-by: Pali Rohár
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_
On Wed, Sep 18, 2013 at 06:43:49PM +0200, Pali Rohár wrote:
> On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> > On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> > > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > > Canillas
> > >
> > > wrote:
> > > > to split
Hi,
On Wed, Sep 18, 2013 at 05:46:10PM +0100, Mark Rutland wrote:
> > > > I even wrote a patch making USB3 PHY optional, but didn't push it
> > > > exactly because it broke some other systems and I can't guarantee users
> > > > won't mess up their DTS/pdata.
> > >
> > > Does that mean that their
More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.
So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting
On Wed, 2013-09-18 at 17:52 +0200, Bjørn Mork wrote:
> No modern device should need the padding. No old device will be able to
> use the SG feature as implemented. You only enable it on USB3, don't
On XHCI.
> you? If this feature is restricted to USB3 capable devices, then it most
> certainly c
Ming Lei writes:
> On Wed, Sep 18, 2013 at 11:52 PM, Bjørn Mork wrote:
>
>> Why don't you test it on the device you tested the SG patch with? I am
>> pretty sure it works just fine using proper ZLP transfer termination.
>
> I should have planned to test it, but didn't know how to build TCP TSO
>
Oliver Neukum wrote:
>On Wed, 2013-09-18 at 17:52 +0200, Bjørn Mork wrote:
>
>> No modern device should need the padding. No old device will be able
>to
>> use the SG feature as implemented. You only enable it on USB3, don't
>
>On XHCI.
>
>> you? If this feature is restricted to USB3 capable devi
Hi Felipe,
I'm getting the following from the dwc3 driver using the dwc3-pci glue
layer, when modprobing the driver. It's not fatal, the driver continues
to work afterwards. Looks like request_threaded_irq() is getting called
with irqs disabled, and it can sleep.
I am unable to test with 3.12-rc1
> From: Paul Zimmerman
> Sent: Wednesday, September 18, 2013 3:13 PM
>
> I'm getting the following from the dwc3 driver using the dwc3-pci glue
> layer, when modprobing the driver. It's not fatal, the driver continues
> to work afterwards. Looks like request_threaded_irq() is getting called
> with
Hi,
On Wed, Sep 18, 2013 at 10:39:34PM +, Paul Zimmerman wrote:
> > From: Paul Zimmerman
> > Sent: Wednesday, September 18, 2013 3:13 PM
> >
> > I'm getting the following from the dwc3 driver using the dwc3-pci glue
> > layer, when modprobing the driver. It's not fatal, the driver continues
>
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Wednesday, September 18, 2013 6:58 PM
>
> On Wed, Sep 18, 2013 at 10:39:34PM +, Paul Zimmerman wrote:
> > > From: Paul Zimmerman
> > > Sent: Wednesday, September 18, 2013 3:13 PM
> > >
> > > I'm getting the following from the dwc3 driver using
In order to increase test coverage, we can change the interval between
two remote wakeups every time, and the interval can be any user defined
value. This change will no affect current behavior if the user does not
use two introduced module parameters.
Signed-off-by: Peter Chen
---
Chagnes for v
As per USB specification, in Suspend state the status bit does
not change until the port is suspended. However, there may be a delay
in suspending a port if there is a transaction currently in progress
on the bus.
In the USBDR controller, the PORTSCx[SUSP] bit changes immediately when
the applicat
On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:
> Oliver Neukum wrote:
> >No, USB 3.0 uses no companion controllers, so you can have devices
> >of any speed connected to it.
> >
>
> Ah, right. I don't own such modern hardware, but I should have known this
> anyway.
>
> This still doesn't
60 matches
Mail list logo
