Hi Peter,
I'm trying to create device tree nodes for USB devices (use case a USB
device providing GPIO and I2C controllers)
Your patch (now merged)
69bec725 "USB: core: let USB device know device node"
looks just like what I need but I have a couple of problems.
First it doesn't work at
On Tue, May 23, 2017 at 11:40:58PM +0200, Harald Welte wrote:
[snip]
> But this weird combination between sysfs on the one hand side and
> directly issuing USB hub control requests via uhubctl on the other side
> really looks ugly. Is this really how one is supposed to power-cycle a
> USB device?
On Monday, May 22, 2017 12:02:09 AM Wolfram Sang wrote:
> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
>
> Signed-off-by: Wolfram Sang
Acked-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/mach-omap1/board-h2-mmc.c | 2 +-
> arch/arm/
On Monday, May 22, 2017 12:02:10 AM Wolfram Sang wrote:
> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
>
> Signed-off-by: Wolfram Sang
Acked-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/mach-omap2/common.h| 2 +-
> arch/arm/
On 27.05.2017 22:26, Corentin Labbe wrote:
When plugging an USB webcam I see the following message:
[106385.615559] xhci_hcd :04:00.0: WARN Successful completion on short TX:
needs XHCI_TRUST_TX_LENGTH quirk?
[106390.583860] handle_tx_event: 913 callbacks suppressed
With this patch applied,
On Fri, May 26, 2017 at 06:26:01AM -0700, Guenter Roeck wrote:
> > > What happens if trace is not enabled ? If I recall discussions around
> > > CLANG
> > > correctly, it complains about unused static inline functions.
> >
> > Nothing happens if trace is not enable. Everything continues to
> > co
On Fri, May 26, 2017 at 06:30:38AM -0700, Guenter Roeck wrote:
> On 05/26/2017 04:08 AM, Heikki Krogerus wrote:
> > Hi,
> >
> > On Thu, May 25, 2017 at 06:23:30AM -0700, Guenter Roeck wrote:
> > > > + /*
> > > > +* NOTE: The memory region for the data structures is used also
> > > >
From: Rafał Miłecki
Hi,
This is another try of adding relation between LEDs and devices to the DT (and
usbport). I followed discussions in all old threads and came with this V3.
I'd epxect both patches to go through Greg's usb.git if accepted.
For a reference (and before someome comes with alr
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
---
This patch *should not* be applied. It's only an EXAMPLE and that's why it uses
that weird 3/2 number.
It's a proof of concept, it was tested & will be submitted through ARM tree if
previous patches get accepted.
V3: Switch to the new bindin
From: Rafał Miłecki
Some LEDs can be related to a specific device(s) described in the DT.
This property allows specifying such relations. E.g. USB LED should
usually be used to indicate some USB port(s) state.
Please note this binding is designed to be generic and not influenced by
any operating
From: Rafał Miłecki
This uses DT info to read relation description of LEDs and USB ports. If
DT has properly described LEDs, trigger will know when to turn them on.
Signed-off-by: Rafał Miłecki
---
V2: Update to use "led-triggers"
V3: Update to use "trigger-sources"
---
drivers/usb/core/ledtri
On 26.05.2017 22:12, gavi...@thegavinli.com wrote:
From: Gavin Li
If a stalling TRB is cancelled and NOOP'ed in xhci_handle_cmd_stop_ep(),
finish_td() never gets called to reset the halted endpoint and the
endpoint remains indefinitely stalled. This patch ensures that
xhci_cleanup_halted_endpoi
On Mon, May 29, 2017 at 11:01:52AM +0200, Martin Fuzzey wrote:
> Hi Peter,
>
> I'm trying to create device tree nodes for USB devices (use case a USB
> device providing GPIO and I2C controllers)
>
> Your patch (now merged)
> 69bec725 "USB: core: let USB device know device node"
>
> looks
On Mon, May 29, 2017 at 04:15:36PM +0200, Johan Hovold wrote:
> On Mon, May 29, 2017 at 11:01:52AM +0200, Martin Fuzzey wrote:
> > However my larger question is that I don't see how to associate a DT
> > node with a USB *interface* rather than a USB *device*.
>
> I started looking into this a wh
A reference is taken when looking up a device-tree node when allocating
a USB device, but the reference is never released.
There are some issues related to how we deal with the root hub and its
node which I'll get back to in a follow up series, but this can go in
meanwhile.
Johan
Johan Hovold (
Make sure to release any OF device-node reference taken when creating
the USB device.
Note that we currently do not hold a reference to the root hub
device-tree node (i.e. the parent controller node).
Fixes: 69bec7259853 ("USB: core: let USB device know device node")
Cc: stable # v4.6
Cc: Pe
Document that the child-node lookup helper takes a reference to the
device-tree node which needs to be dropped after use.
Signed-off-by: Johan Hovold
---
drivers/usb/core/of.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index d563cbcf76cf.
Hi
I doesn't works for me.
Device is Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. /
JMicron USA Technology Corp.
Always got this when plugged:
[ 211.577287] xhci_hcd :00:14.0: ERROR Transfer event for disabled
endpoint or incorrect stream ring
[ 211.577317] xhci_hcd :00:1
More info:
Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA
Technology Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPack
Sorry Bjorn,
your solution seems good!
I had to regenerate initramfs.
To understand better, is it a real bug on kernel about uas ?
Le 22/05/2017 à 08:00, Bjørn Forsman a écrit :
> On 3 May 2017 at 10:07, Oliver Neukum wrote:
>> Am Dienstag, den 02.05.2017, 20:06 +0200 schrieb Nicolas Repentin
On 05/29/2017 05:33 AM, Heikki Krogerus wrote:
On Fri, May 26, 2017 at 06:26:01AM -0700, Guenter Roeck wrote:
What happens if trace is not enabled ? If I recall discussions around CLANG
correctly, it complains about unused static inline functions.
Nothing happens if trace is not enable. Everyt
Hi Rafał,
On 05/29/2017 04:01 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Some LEDs can be related to a specific device(s) described in the DT.
> This property allows specifying such relations. E.g. USB LED should
> usually be used to indicate some USB port(s) state.
>
> Please note this
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan Sridhara
Thanks for all the reviews Guenter & Heikki.
Heikki, Is there anything else that I need to address in this patch ?
Or is the patch ready to be merged ?
Thanks,
Badhri
On Mon, May 29, 2017 at 12:56 PM, Badhri Jagan Sridharan
wrote:
> User space applications in some cases have the need to enforce
On 29 May 2017 at 21:52, Jacek Anaszewski wrote:
> On 05/29/2017 04:01 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> Some LEDs can be related to a specific device(s) described in the DT.
>> This property allows specifying such relations. E.g. USB LED should
>> usually be used to indicate
On Mon, May 22, 2017 at 6:58 PM, Jassi Brar wrote:
> On Thu, May 18, 2017 at 4:07 AM, Ruslan Bilovol
> wrote:
>> Abstract the peripheral side ALSA sound card code from
>> the f_uac2 function into a component that can be called
>> by various functions, so the various flavors can be split
>> apart
On Fri, May 26, 2017 at 6:52 PM, Julian Scheel wrote:
> On 18.05.2017 00:37, Ruslan Bilovol wrote:
>>
>> This patch adds a new function 'f_uac1_acard'
>> (f_uac1 with virtual "ALSA card") that
>> uses recently created u_audio API. Comparing
>> to legacy f_uac1 function implementation it
>> doesn't
You are correct; it seems like this issue arises from the fact that
stalled no-op trbs are ignored and the controller remains stuck in the
Halted state because the Reset Endpoint command never gets run.
>From what I understand, this issue is not caused by losing track of
where the endpoint ring st
> On 24 May 2017, at 21:40, Christoph Gohle wrote:
>
>>
>>> On 22 May 2017, at 14:37, Mathias Nyman
>>> wrote:
>>>
>>> On 22.05.2017 11:48, Christoph Gohle wrote:
Hey Mathias,
> On 19 May 2017, at 09:58, Mathias Nyman
> wrote:
>
>>
>
> 4.11 kerne
29 matches
Mail list logo
