Hi,
Paul Zimmerman writes:
> Felipe Balbi writes:
>
>> If we're going to issue a Update Transfer command,
>> let's clear LST bit from previous TRB. This will let
>> us continue processing TRBs and convert previous IRQ
>> into XferInProgress, instead of XferComplete.
>>
>> Signed-off-by: Felipe
Hi,
John Youn writes:
>> @@ -1589,6 +1578,46 @@ static void dwc3_gadget_disable_irq(struct dwc3 *dwc)
>> static irqreturn_t dwc3_interrupt(int irq, void *_dwc);
>> static irqreturn_t dwc3_thread_interrupt(int irq, void *_dwc);
>>
>> +/**
>> + * dwc3_gadget_setup_nump - Calculate and initiali
Hi Felipe,
I see you touched some stuff with the trb calculations in your recent
dwc3 patch series. I had very similar changes in my tree in which I'm
doing some isoc enhancements. So I rebased them against your patches
and tested. They seem to work ok so far and they fix a couple issues
with the
Make the skipping of the link TRBS build-in to the increment and
decrement operations. This simplifies the code wherever we increment and
decrement and ensures that we never end up pointing to a link trb.
Signed-off-by: John Youn
---
drivers/usb/dwc3/gadget.c | 26 +-
1 f
This patch fixes up some issues related to the trb_left calculation.
This calculation sometimes included the link trb slot in the trbs_left
and sometimes didn't.
In the case where the dequeue < enqueue, this number does not include
the link trb and should be used as-is. Otherwise it will include
Hi,
John Youn writes:
> Make the skipping of the link TRBS build-in to the increment and
> decrement operations. This simplifies the code wherever we increment and
> decrement and ensures that we never end up pointing to a link trb.
>
> Signed-off-by: John Youn
I had this in my TODO for today
On 18/05/16 17:46, Jun Li wrote:
>
>
I didn't want to have complex Kconfig so decided to have otg as
built-in only.
What do you want me to change in existing code? and why?
>>>
>>> Remove those stuff which only for pass diff driver config Like every
>>> controller driver need
On Thu, May 19 2016, Changbin Du wrote:
>> On Wed, May 18 2016, Felipe Balbi wrote:
>> > we've been through this before. This needs to be done at the gadget
>> > layer. Gadget driver can over-allocate ahead of time if
>> > gadget->quirk_ep_out_aligned_size is true, then we avoid memcpy() at
>> > th
Hi,
John Youn writes:
> This patch fixes up some issues related to the trb_left calculation.
>
> This calculation sometimes included the link trb slot in the trbs_left
> and sometimes didn't.
good catch. But this patch seems like it can be broken into smaller
pieces. See below
> In the case wh
Hi,
> > I'd prefer fail the request at all, and it is better done in HW.
> > Because per the USB Spec that device can return NAK if a function was
> > unable to accept data From the host. The DWC3 has not been design as
> > this, if software fail the transfer, it is a little weird for host.
> >
>
Hi Felipe,
I am trying to bring up a DWC USB 3.0 Host with linux (v4.6-rc5) running in a
ARM64 development board.
I have implemented the following suggested fix to overcome the DMA problem I was
having:
https://lkml.org/lkml/2016/3/31/609
I received one interrupt but I am getting cyclic crashes
From: Rafal Redzimski
Current implementation updates the mtu size and notify cdc_ncm
device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram
size change instead of changing rx_urb_size.
Whenever mtu is being changed, datagram size should also be
updated. Also updating maxmtu formula so
Hi João,
Adding Mathias, who's xHCI's maintainer
Joao Pinto writes:
> Hi Felipe,
>
> I am trying to bring up a DWC USB 3.0 Host with linux (v4.6-rc5)
> running in a ARM64 development board.
Just to be clear, is this Juno with dwc3 in FPGA or do you have dwc3 in ASIC?
> I have implemented the
Hi Felipe!
On 5/19/2016 10:57 AM, Felipe Balbi wrote:
>
> Hi João,
>
> Adding Mathias, who's xHCI's maintainer
>
> Joao Pinto writes:
>> Hi Felipe,
>>
>> I am trying to bring up a DWC USB 3.0 Host with linux (v4.6-rc5)
>> running in a ARM64 development board.
>
> Just to be clear, is this Jun
This patch protects system from crashing at shutdown in
cases where usb host is not added yet from OTG controller driver.
As ehci_setup() not done yet, so stop accessing registers or
variables initialized as part of ehci_setup().
The use case is simple, for boards like DB410c where the usb host
or
Hi Felipe and Mathias,
Sending kernel log with extra xhci messages in attachment!
Thanks you for the help!
On 5/19/2016 11:02 AM, Joao Pinto wrote:
> Hi Felipe!
>
> On 5/19/2016 10:57 AM, Felipe Balbi wrote:
>>
>> Hi João,
>>
>> Adding Mathias, who's xHCI's maintainer
>>
>> Joao Pinto writes:
>
Hi,
Joao Pinto writes:
> Hi Felipe and Mathias,
>
> Sending kernel log with extra xhci messages in attachment!
> Thanks you for the help!
yeah, no problems. So here's the interesting part:
*INSERTING PEN DRIVE
# xhci-hcd xhci-hcd.0.auto: Port Status Chang
Hi Felipe,
On 5/19/2016 11:32 AM, Felipe Balbi wrote:
>
> Hi,
>
> Joao Pinto writes:
>> Hi Felipe and Mathias,
>>
>> Sending kernel log with extra xhci messages in attachment!
>> Thanks you for the help!
>
> yeah, no problems. So here's the interesting part:
>
>***
On 19.05.2016 14:23, Joao Pinto wrote:
Hi Felipe,
On 5/19/2016 11:32 AM, Felipe Balbi wrote:
Hi,
Note that we really did get a command timeout. Can you add a little
extra debugging to try and figure out why that command failed?
After instrumenting and capturing FPGA signals, the driver co
Hi,
Joao Pinto writes:
> Hi Felipe,
>
> On 5/19/2016 11:32 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Joao Pinto writes:
>>> Hi Felipe and Mathias,
>>>
>>> Sending kernel log with extra xhci messages in attachment!
>>> Thanks you for the help!
>>
>> yeah, no problems. So here's the interesting
The purpose of this class is to provide unified interface for user
space to get the status and basic information about USB Type-C
Connectors in the system, control data role swapping, and when USB PD
is available, also power role swapping and Alternate Modes.
Signed-off-by: Heikki Krogerus
---
d
Hi Mathias and Felipe,
On 5/19/2016 1:22 PM, Mathias Nyman wrote:
> On 19.05.2016 14:23, Joao Pinto wrote:
>> Hi Felipe,
>>
>> On 5/19/2016 11:32 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>>
>>> Note that we really did get a command timeout. Can you add a little
>>> extra debugging to try and figu
I'm trying to establish a high performance USB connection from device/gadget to
host. On the USB gadget side I'm running on a Atmel ATSAMA5D35-EK. The Linux
Kernel version is 4.1 (4.1.0-linux4sam_5.2-00045-g633e08a) and I'm using
configfs to set things up.
I strictly followed the steps accordin
Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.
Signed-off-by: Muhammad Falak R Wani
---
drivers/net/usb/ch9200.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/
Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.
Signed-off-by: Muhammad Falak R Wani
---
drivers/usb/serial/cp210x.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --gi
On Thu, 19 May 2016, Srinivas Kandagatla wrote:
> This patch protects system from crashing at shutdown in
> cases where usb host is not added yet from OTG controller driver.
> As ehci_setup() not done yet, so stop accessing registers or
> variables initialized as part of ehci_setup().
>
> The use
Hi,
I've been going through the drivers with an eye on security.
And a question arose. How do we know that a device that claims
to be a chaoskey is really a chaoskey?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> The purpose of this class is to provide unified interface for user
> space to get the status and basic information about USB Type-C
> Connectors in the system, control data role swapping, and when USB PD
> is available, also power role swa
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> + dev->class = &typec_class;
> + dev->parent = parent;
> + dev->type = &typec_partner_dev_type;
> + dev_set_name(dev, "%s-partner", dev_name(&port->dev));
> +
> + ret = device_register(dev);
> + if (ret) {
> +
Properly sort all the entries by vendor id.
Signed-off-by: Hans de Goede
---
Changes in v2:
-This is a new patch in v2 of this patch-set
---
drivers/usb/core/quirks.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/core/quirks.c b/drivers/us
The Acer C120 LED Projector is a USB-3 connected pico projector which
takes both its power and video data from USB-3.
In combination with some hubs this device does not play well with
lpm, so disable lpm for it.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Properly sort entries by vendor id
If the session bit was not set in the backup of devctl register,
restoring devctl would clear the session bit. Therefor, only restore
devctl register when the session bit was set in the backup.
This solves the device enumeration failure in otg mode exposed by commit
56f487c (PM / Runtime: Update l
Hi,
* Bin Liu [160518 11:12]:
> On Wed, May 18, 2016 at 11:07:37AM -0700, Tony Lindgren wrote:
> >
> > Is this with or without the $subject series?
>
> Without.
OK sounds like you have a fix coming for that issue.
> > > I tried to enable some dynamic-debug log, but was unable to see any
> > >
On 19 May 2016 at 01:52, Peter Chen wrote:
>
>
> On Thu, May 19, 2016 at 5:24 AM, Arnd Bergmann wrote:
>>
>> I stumbled over this warning last week, which showed up after I had
>> removed an incorrect patch from my randconfig build setup:
>>
>> drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_
Hi Felipe and Mathias,
On 5/19/2016 1:22 PM, Mathias Nyman wrote:
> On 19.05.2016 14:23, Joao Pinto wrote:
>> Hi Felipe,
>>
>> On 5/19/2016 11:32 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>>
>>> Note that we really did get a command timeout. Can you add a little
>>> extra debugging to try and figur
After a few moments the schedule problem happen again:
# INFO: task kworker/0:1:349 blocked for more than 120 seconds.
Not tainted 4.6.0-rc5 #9
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:1 D ff8008086c60 0 349 2 0x
Workqueu
On Thu, May 19, 2016 at 04:48:46PM +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
>
> > + dev->class = &typec_class;
> > + dev->parent = parent;
> > + dev->type = &typec_partner_dev_type;
> > + dev_set_name(dev, "%s-partner", dev_name(&port->dev));
> From: Bin Liu [mailto:b-...@ti.com]
> Hi,
>
> On Fri, May 06, 2016 at 10:41:46AM +, Andrew Goodbody wrote:
> > > From: Bin Liu [mailto:b-...@ti.com]
> > > On Thu, May 05, 2016 at 04:02:55PM +, Andrew Goodbody wrote:
> > > > > From: Bin Liu [mailto:b-...@ti.com] On Thu, May 05, 2016 at
>
2016-05-18 22:28 GMT+03:00 Alan Stern :
> On Wed, 18 May 2016, Andrey Ryabinin wrote:
>
>> 2016-05-18 19:09 GMT+03:00 Alan Stern :
>> > On Wed, 18 May 2016, Andrey Ryabinin wrote:
>> >
>> >> 2016-05-18 17:40 GMT+03:00 Alan Stern :
>> >>
>> >> > All right, I'm getting very tired of all these bug rep
Oliver Neukum writes:
> Hi,
>
> I've been going through the drivers with an eye on security.
> And a question arose. How do we know that a device that claims
> to be a chaoskey is really a chaoskey?
A fine question, and one we've thought about extensively.
The Chaoskey device explicitly does no
Hello,
I’ve been learning about and playing with configfs and functionfs to create
composite user space USB gadgets. My objective is to create a composite USB
gadget that incorporates a custom functionfs function of my own creation along
with some _real_ USB devices connected to my linux platfo
* Tony Lindgren [160519 08:28]:
> +static void dsps_musb_set_power(struct musb *musb, bool enabled)
> +{
> + struct dsps_glue *glue = dev_get_drvdata(musb->controller->parent);
> + int err;
> +
> + if (enabled == glue->powered) {
> + dev_warn(musb->controller, "Power alread
Hello Heikki,
On Thu, May 19, 2016 at 03:44:54PM +0300, Heikki Krogerus wrote:
> The purpose of this class is to provide unified interface for user
> space to get the status and basic information about USB Type-C
> Connectors in the system, control data role swapping, and when USB PD
> is availabl
On 5/19/2016 12:51 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> This patch fixes up some issues related to the trb_left calculation.
>>
>> This calculation sometimes included the link trb slot in the trbs_left
>> and sometimes didn't.
>
> good catch. But this patch seems like it can
Robert Dobrowolski writes:
> From: Rafal Redzimski
>
> Current implementation updates the mtu size and notify cdc_ncm
> device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram
> size change instead of changing rx_urb_size.
>
> Whenever mtu is being changed, datagram size should also be
From: Heinrich Schuchardt
Date: Wed, 18 May 2016 02:13:30 +0200
> (!count || count < 4) is always true.
> So let's remove the coding which is dead at least since 2005.
>
> Signed-off-by: Heinrich Schuchardt
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the
On 18 May 2016 at 16:24, Arnd Bergmann wrote:
> +/*
> + * This abstracts the TCSR register area in Qualcomm SoCs, originally
> + * introduced by Tim Bird as part of the phy-msm-usb.ko device driver,
> + * and split out by Arnd Bergmann into a separate file.
> + *
> + * This file shouldn't reall
Dave Tian writes:
> BadUSB[1] attacks show that everyone can change the firmware adding
> new functionalities/interfaces, e.g., a usb driver with a
> keyboard/input interface. The question seems deeper than it looks like
> - we/users probably want to know:
Oh, good point -- I don't think anyone
On Thu, 2016-05-19 at 14:12 -0400, Dave Tian wrote:
> > The Chaoskey device explicitly does not address physical
> > attacks. Assuming physical security makes things a lot easier, and
> > one
> > of the simplifications is that we can assume that any physical
> > device
> > connected to the machin
Oliver Neukum writes:
> I think we would need to use a form of public key cryptography
> in the same manner used to verify authorship of emails. The host
> would provide a nonce value that the device encrypts and returns.
> The host would verify the signature.
We're shipping the device containin
On Thu, 2016-05-19 at 12:52 -0700, Keith Packard wrote:
> Oliver Neukum writes:
>
> > I think we would need to use a form of public key cryptography
> > in the same manner used to verify authorship of emails. The host
> > would provide a nonce value that the device encrypts and returns.
> > The h
On Thu, 19 May 2016, Andrey Ryabinin wrote:
> 2016-05-18 22:28 GMT+03:00 Alan Stern :
> > On Wed, 18 May 2016, Andrey Ryabinin wrote:
> >
> >> 2016-05-18 19:09 GMT+03:00 Alan Stern :
> >> > On Wed, 18 May 2016, Andrey Ryabinin wrote:
> >> >
> >> >> 2016-05-18 17:40 GMT+03:00 Alan Stern :
> >> >>
>
Oliver Neukum writes:
> Good point. The logical answer would be to not ship the key. That means
> that users would "format" their chaoskeys and get their private key into
> the kernel by an attribute or ioctl.
Now *there's* a good idea. Ship the firmware and firmware loader and
have the user gen
On Thu, 2016-05-19 at 21:59 +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 12:52 -0700, Keith Packard wrote:
> > Oliver Neukum writes:
> >
> > > I think we would need to use a form of public key cryptography
> > > in the same manner used to verify authorship of emails. The host
> > > would p
Several people have reported that UBSAN doesn't like the pointer
arithmetic in ehci_hub_control():
u32 __iomem *status_reg = &ehci->regs->port_status[
(wIndex & 0xff) - 1];
u32 __iomem *hostpc_reg = &ehci->regs->hostpc[(wIndex & 0xff) - 1];
On 19 May 2016 at 05:12, Srinivas Kandagatla
wrote:
> This patch protects system from crashing at shutdown in
> cases where usb host is not added yet from OTG controller driver.
> As ehci_setup() not done yet, so stop accessing registers or
> variables initialized as part of ehci_setup().
>
> The
On 19 May 2016 at 05:12, Srinivas Kandagatla
wrote:
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -368,6 +368,15 @@ static void ehci_shutdown(struct usb_hcd *hcd)
> {
> struct ehci_hcd *ehci = hcd_to_ehci(hcd);
>
> + /**
> +* Protect the system from crashing at system shutdown
UBSAN throws a complaint:
[2.418579] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47
[2.418582] index -1 is out of range for type 'u32 [1]'
though it's only on the hostpc[] part, not on the port_status[] on the
previous line which has the same exact index calculation. T
Oliver Neukum writes:
> I think we would need to use a form of public key cryptography
> in the same manner used to verify authorship of emails. The host
> would provide a nonce value that the device encrypts and returns.
> The host would verify the signature.
We could initially provision the de
The current calculation takes dep->trb_dequeue - dep->trb_enqueue to
find the TRB space left.
If you enqueue 1, that results in:
(u8) 0 - (u8) 1 = 0xff = 255 TRBs left.
This is correct if DWC3_TRB_NUM == 256.
If DWC3_TRB_NUM is less than 256 (but still a power of 2) you need to
mod the result by
The TRBs left calculation didn't account for the link TRB taking up one
spot.
If the trb_dequeue < trb_enqueue, then the result includes the link
TRB slot so it must be adjusted.
Signed-off-by: John Youn
---
drivers/usb/dwc3/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/driver
Clears out all the TRBs in the ring to clean up any stale data that
might be in them from the previous time the endpoint was enabled.
Also removed the existing clear of the LINK trb since the entire ring is
cleard just before.
Signed-off-by: John Youn
---
drivers/usb/dwc3/gadget.c | 8 ++--
If the trb->enqueue == trb->dequeue, then it could be full or empty.
This could also happen at TRB index 0, so modify the check to handle
that condition. At index 0, the previous TRB is the one just before the
link TRB.
Signed-off-by: John Youn
---
drivers/usb/dwc3/gadget.c | 28
Make the skipping of the link TRBS built-in to the increment operation.
This simplifies the code wherever we increment the trb index and ensures
that we never end up pointing to a link trb.
Signed-off-by: John Youn
---
drivers/usb/dwc3/gadget.c | 34 --
1 file cha
This series addresses a few issues with the TRB ring handling and
calculation of free space on the ring.
v2:
- Split up patches into individual fixes with better descriptions.
- Added dwc3_ep_prev_trb() to get the previous TRB.
- Moved the increment calculation into one function and documented it.
If trbs_left == 0, we don't have any space left in the TRB ring so don't
prepare anything.
Signed-off-by: John Youn
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c7f1c17..ab22a46 100644
--- a/driver
On Thu, May 19, 2016 at 05:19:00PM -0400, Valdis Kletnieks wrote:
> UBSAN throws a complaint:
>
> [2.418579] UBSAN: Undefined behaviour in
> drivers/usb/host/ehci-hub.c:877:47
> [2.418582] index -1 is out of range for type 'u32 [1]'
>
> though it's only on the hostpc[] part, not on the
On Thu, 19 May 2016 17:50:31 -0700, Greg Kroah-Hartman said:
> On Thu, May 19, 2016 at 05:19:00PM -0400, Valdis Kletnieks wrote:
> > UBSAN throws a complaint:
> >
> > [2.418579] UBSAN: Undefined behaviour in
> > drivers/usb/host/ehci-hub.c:877:47
> > [2.418582] index -1 is out of range for
On Wed, May 18, 2016 at 03:45:11PM +0300, Roger Quadros wrote:
> On 18/05/16 06:18, Peter Chen wrote:
> > On Mon, May 16, 2016 at 12:51:53PM +0300, Roger Quadros wrote:
> >> On 16/05/16 12:23, Peter Chen wrote:
> >>> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
> Hi,
>
>
> On May 19, 2016, at 10:59 PM, Dave Tian wrote:
>
>
>
>> On May 19, 2016, at 8:06 PM, Keith Packard wrote:
>>
>> Oliver Neukum writes:
>>
>>> I think we would need to use a form of public key cryptography
>>> in the same manner used to verify authorship of emails. The host
>>> would prov
Dave Tian writes:
> I am personally in favor of a TPM-like solution, since we probably
> couldn’t/shouldn’t disable the firmware update anyway,
> and we really need a hardware root of trust (with a key embedded) in
> the device, like the TPM in the host.
I don't think we need a true TPM in the h
71 matches
Mail list logo
