On Tue, Oct 22, 2019 at 11:57:53PM -0700, Jack Pham wrote:
> USB 3.x SuperSpeed peripherals can draw up to 900mA of VBUS power
> when in configured state. However, if a configuration wanting to
> take advantage of this is added with MaxPower greater than 500
> (currently possible if using a ConfigF
Hi,
Jack Pham writes:
> USB 3.x SuperSpeed peripherals can draw up to 900mA of VBUS power
> when in configured state. However, if a configuration wanting to
> take advantage of this is added with MaxPower greater than 500
> (currently possible if using a ConfigFS gadget) the composite
> driver f
On Tue, Oct 22, 2019 at 08:43:40PM +, Ajay Gupta wrote:
> Hi Heikki,
>
> > -Original Message-
> > From: linux-usb-ow...@vger.kernel.org
> > On Behalf Of Heikki Krogerus
> > Sent: Tuesday, October 22, 2019 12:41 AM
> > To: Ajay Gupta
> > Cc: Greg Kroah-Hartman ; Guenter Roeck
> > ; li
Sebastian suggested to try this here:
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1264,8 +1264,11 @@ static void lan78xx_status(struct lan78xx_net *dev,
struct urb *urb)
netif_dbg(dev, link, dev->net, "PHY INTR: 0x%08x\n", intdata);
lan78xx_
On 2019-10-23 00:49, Felipe Balbi wrote:
Hi,
Jack Pham writes:
USB 3.x SuperSpeed peripherals can draw up to 900mA of VBUS power
when in configured state. However, if a configuration wanting to
take advantage of this is added with MaxPower greater than 500
(currently possible if using a Config
On Tue, Sep 24, 2019 at 08:14:00PM +0800, Charles Yeh wrote:
> Prolific has developed a new USB to UART chip: PL2303HXN
> PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
> The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
> the existing PL2303 series (TYPE_HX &
Hi folks,
I'm trying to find out which CPU's that are supported by Linux have
USB controllers that support gadget mode.
In theory, this should be a relatively straightforward matter, given
the device tree descriptions, I think. But I am struggling to figure
out how to actually create a list of th
Hi, all
We found that this is a known issue of synopsys DWC3 USB controller,
when the PARKMODE_SS of DWC3 is enable, the controller may hang or do
wrong TRB schedule in some heavy load conditions.
Setting DISABLE_PARKMODE_SS to 1 can work around this bug.
Thank you for your help.
alex zheng 于2
Hi,
(please don't top-post)
alex zheng writes:
> Hi, all
>
> We found that this is a known issue of synopsys DWC3 USB controller,
> when the PARKMODE_SS of DWC3 is enable, the controller may hang or do
> wrong TRB schedule in some heavy load conditions.
>
> Setting DISABLE_PARKMODE_SS to 1 can
The five removed symbols are unused since they were introduced in commit
3ec72a2a1e5d ("usb: misc: add USB251xB/xBi Hi-Speed Hub Controller
Driver") back in 2017.
Signed-off-by: Uwe Kleine-König
---
drivers/usb/misc/usb251xb.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/m
The USB2422 uses a different package that the USB251x and only comes in
a variant with 2 downstream ports. Other than that it is software
compatible.
Tested-by: Carsten Stelling
Signed-off-by: Uwe Kleine-König
---
drivers/usb/misc/usb251xb.c | 12
1 file changed, 12 insertions(+)
The next patch introduces support for the USB2422. Add it to the list of
devices supported by the binding.
Signed-off-by: Uwe Kleine-König
---
Documentation/devicetree/bindings/usb/usb251xb.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/
On Wed, 23 Oct 2019, Christoph Hellwig wrote:
> On Mon, Oct 21, 2019 at 11:48:06AM -0400, Alan Stern wrote:
> > There is no longer any reason to keep the virt_boundary_mask setting
> > for usb-storage. It was needed in the first place only for handling
> > devices with a block size smaller than t
Supplying the operation callbacks as part of a struct
typec_operations instead of as part of struct
typec_capability during port registration.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/tcpm/tcpm.c | 45 ---
1 file changed, 20
Introducing struct typec_operations which has the same
callbacks as struct typec_capability. The old callbacks are
kept for now, but after all users have been converted, they
will be removed.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/class.c | 39 ++
Hi,
There is now a check in ucsi_exec_command() that makes sure we do not
call ucsi_read_error() with UCSI_GET_ERROR_STATUS command. That should
prevent endless recursion from happening.
The original cover letter:
The first patches in this series (patches 1-8) introduce a small
change to the USB
The members for the muxes are not used, so dropping them.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
include/linux/usb/typec.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 894798084319..0f52723a11bd 100644
--
Replacing the old "cmd" and "sync" callbacks with an
implementation of struct ucsi_operations. The ACPI
notification (interrupt) handler will from now on read the
CCI (Command Status and Connector Change Indication)
register, and call ucsi_connector_change() function and/or
complete pending command
Replacing the old "cmd" and "sync" callbacks with an
implementation of struct ucsi_operations. The interrupt
handler will from now on read the CCI (Command Status and
Connector Change Indication) register, and call
ucsi_connector_change() function and/or complete pending
command completions based o
Supplying the operation callbacks as part of a struct
typec_operations instead of as part of struct
typec_capability during port registration. After this there
is not need to keep the capabilities stored anywhere in the
driver.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drive
The drivers now only use the new API, so removing the old one.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/ucsi/displayport.c | 24 +-
drivers/usb/typec/ucsi/trace.h | 17 --
drivers/usb/typec/ucsi/ucsi.c| 346 +++
drivers/usb/typec/ucsi/ucsi.h
There is no need to reset the PPM when the interface is
unregistered. Quietly silencing the notifications and then
unregistering everything is enough. This speeds up
ucsi_unregister() a lot.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/ucsi/ucsi.c | 9 +++--
1 file changed, 3 inserti
Adding new error codes to the driver that were introduced in
UCSI specification v1.1.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/ucsi/ucsi.c | 25 -
drivers/usb/typec/ucsi/ucsi.h | 6 ++
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/driver
Supplying the operation callbacks as part of a struct
typec_operations instead of as part of struct
typec_capability during port registration.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/ucsi/ucsi.c | 22 +++---
1 file changed, 11 insertions(+
Supplying the operation callbacks as part of a struct
typec_operations instead of as part of struct
typec_capability during port registration. After this there
is not need to keep the capabilities stored anywhere in the
driver.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drive
There are no more users for them.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/class.c | 40 +++
include/linux/usb/typec.h | 17 -
2 files changed, 11 insertions(+), 46 deletions(-)
diff --git a/drivers/usb/
That data structure was used for constructing the commands
before executing them, but it was never really useful. Using
the structure just complicated the driver. The commands are
64-bit wide, so it is enough to simply fill a u64 variable.
No data structures needed.
This simplifies the driver cons
We can't use bit fields with data that is received or send
to/from the device.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/ucsi/trace.h | 12 ++---
drivers/usb/typec/ucsi/ucsi.c | 52 +++
drivers/usb/typec/ucsi/ucsi.h | 93 +-
3 files ch
Copying everything from struct typec_capability to struct
typec_port during port registration. This will make sure
that under no circumstances the driver can change the values
in the struct typec_capability that the port uses.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
driver
The driver already finds the node in order to get reference
to the USB role switch.
Signed-off-by: Heikki Krogerus
Tested-by: Biju Das
---
drivers/usb/typec/hd3ss3220.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/typec/hd3ss3220.c b/drivers/usb/t
Leaving the private driver_data pointer of the port device
to the port drivers.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/class.c | 11 +++
include/linux/usb/typec.h | 4
2 files changed, 15 insertions(+)
diff --git a/drivers/usb/typec/class.
Adding more simplified API for interface registration and
read and write operations.
The registration is split into separate creation and
registration phases. That allows the drivers to properly
initialize the interface before registering it if necessary.
The read and write operations are supplie
* Vinod Koul [191023 04:54]:
> Hi Tony,
>
> On 22-10-19, 07:55, Tony Lindgren wrote:
>
> Patch subject should reflect the patch changes not the fix. The patch
> title here is not telling me anything about the change below. Pls
> consider updating the title.
Sure, I'll resend with updated descri
Yegor Yefremov reported that musb and ftdi
uart can fail for the first open of the uart unless connected using
a hub.
This is because the first dma call done by musb_ep_program() must wait
if cppi41 is PM runtime suspended. Otherwise musb_ep_program() continues
with other non-dma packets before t
Commit 3ae62a42090f ("UAS: fix alignment of scatter/gather segments"),
copying a similar commit for usb-storage, attempted to solve a problem
involving scatter-gather I/O and USB/IP by setting the
virt_boundary_mask for mass-storage devices.
However, it now turns out that the analogous change in u
On 23-10-19, 08:31, Tony Lindgren wrote:
> Yegor Yefremov reported that musb and ftdi
> uart can fail for the first open of the uart unless connected using
> a hub.
>
> This is because the first dma call done by musb_ep_program() must wait
> if cppi41 is PM runtime suspended. Otherwise musb_ep_pr
Hi Heikki
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org
> On Behalf Of Heikki Krogerus
> Sent: Wednesday, October 23, 2019 1:06 AM
> To: Ajay Gupta
> Cc: Greg Kroah-Hartman ; Guenter Roeck
> ; linux-usb@vger.kernel.org
> Subject: Re: [PATCH 00/18] usb: typec: API improveme
Hi Heikki
> -Original Message-
> From: Heikki Krogerus
> Sent: Wednesday, October 23, 2019 7:40 AM
> To: Greg Kroah-Hartman
> Cc: Guenter Roeck ; Ajay Gupta ;
> linux-usb@vger.kernel.org
> Subject: [PATCH v2 13/18] usb: typec: ucsi: ccg: Move to the new API
>
> Replacing the old "cmd" a
Linuxhttps://llk.dk/8urvkl Joe Bryant
Hi Tony,
On 10/23/19 6:31 PM, Tony Lindgren wrote:
> Yegor Yefremov reported that musb and ftdi
> uart can fail for the first open of the uart unless connected using
> a hub.
>
> This is because the first dma call done by musb_ep_program() must wait
> if cppi41 is PM runtime suspended. Otherwise
* Peter Ujfalusi [191023 17:04]:
> On 10/23/19 6:31 PM, Tony Lindgren wrote:
> > diff --git a/drivers/dma/ti/cppi41.c b/drivers/dma/ti/cppi41.c
> > --- a/drivers/dma/ti/cppi41.c
> > +++ b/drivers/dma/ti/cppi41.c
> > @@ -586,9 +586,22 @@ static struct dma_async_tx_descriptor
> > *cppi41_dma_prep_s
Hello!
On 10/23/2019 06:31 PM, Tony Lindgren wrote:
> Yegor Yefremov reported that musb and ftdi
> uart can fail for the first open of the uart unless connected using
> a hub.
>
> This is because the first dma call done by musb_ep_program() must wait
> if cppi41 is PM runtime suspended. Otherwi
On Wed, Oct 23, 2019 at 9:55 PM Sergei Shtylyov
wrote:
> On 10/23/2019 06:31 PM, Tony Lindgren wrote:
> > + int error;
> > +
> > + error = pm_runtime_get(cdd->ddev.dev);
> > + if (error < 0) {
>
>I'd call that variable 'status', comparison (error < 0) just doesn't look
> right.
>
* Sergei Shtylyov [191023 18:56]:
> On 10/23/2019 06:31 PM, Tony Lindgren wrote:
> > --- a/drivers/dma/ti/cppi41.c
> > +++ b/drivers/dma/ti/cppi41.c
> > @@ -586,9 +586,22 @@ static struct dma_async_tx_descriptor
> > *cppi41_dma_prep_slave_sg(
> > enum dma_transfer_direction dir, unsigned long
On 10/23/19 8:16 PM, Tony Lindgren wrote:
> * Peter Ujfalusi [191023 17:04]:
>> On 10/23/19 6:31 PM, Tony Lindgren wrote:
>>> diff --git a/drivers/dma/ti/cppi41.c b/drivers/dma/ti/cppi41.c
>>> --- a/drivers/dma/ti/cppi41.c
>>> +++ b/drivers/dma/ti/cppi41.c
>>> @@ -586,9 +586,22 @@ static struct
* Peter Ujfalusi [191023 19:02]:
> On 10/23/19 8:16 PM, Tony Lindgren wrote:
> > * Peter Ujfalusi [191023 17:04]:
> >> On 10/23/19 6:31 PM, Tony Lindgren wrote:
> >>> diff --git a/drivers/dma/ti/cppi41.c b/drivers/dma/ti/cppi41.c
> >>> --- a/drivers/dma/ti/cppi41.c
> >>> +++ b/drivers/dma/ti/cppi
Hello!
On 10/23/2019 09:58 PM, Andy Shevchenko wrote:
>>> + int error;
>>> +
>>> + error = pm_runtime_get(cdd->ddev.dev);
>>> + if (error < 0) {
>>
>>I'd call that variable 'status', comparison (error < 0) just doesn't look
>> right.
>> If it was *if* (error), it would have been
47 matches
Mail list logo
