Implement the mechanism for optional explicit status stage for the MUSB
driver. This allows a function driver to specify what to reply for the
status stage. The functionality for an implicit status stage is
retained.
Signed-off-by: Paul Elder
v1 Reviewed-by: Laurent Pinchart
v1 Acked-by: Bin Liu
This patch series adds a mechanism to allow asynchronously validating
the data stage of a control OUT request, and for stalling or suceeding
the request accordingly. This mechanism is implemented for MUSB, and is
used by UVC. At the same time, UVC packages the setup stage and data
stage data togeth
Since "usb: gadget: uvc: enqueue uvc_request_data in setup handler
for control OUT requests" it is no longer necessary for userspace to
call ioctl UVCIOC_SEND_RESPONSE in response to receiving a
UVC_EVENT_SETUP from the uvc function driver for a control OUT request.
This change means that for cont
A usb gadget function driver may or may not want to delay the status
stage of a control OUT request. An instance where it might want to is to
asynchronously validate the data of a class-specific request.
A function driver that wants an explicit status stage should set the
newly added explicit_stat
We now have a mechanism to signal the UDC driver to reply to a control
OUT request with STALL or ACK, and we have packaged the setup stage data
and the data stage data of a control OUT request into a single
UVC_EVENT_DATA for userspace to consume. The ioctl UVCIOC_SEND_RESPONSE
in the case of a con
V4L2_EVENT_PRIVATE_START is used in g_uvc.h but is defined in
videodev2.h, which is not included and causes a compiler warning:
linux/usb/g_uvc.h:15:28: error: ‘V4L2_EVENT_PRIVATE_START’ undeclared here (not
in a function)
#define UVC_EVENT_FIRST (V4L2_EVENT_PRIVATE_START + 0)
Include videode
Currently, for uvc class-specific control IN and OUT requests, in the
setup handler a UVC_EVENT_SETUP with the setup control is enqueued to
userspace. In response to this, the uvc function driver expects
userspace to call ioctl UVCIOC_SEND_RESPONSE containing uvc request
data.
In the case of contr
> On Jan 5, 2019, at 10:14 PM, Mark Lord wrote:
>
> A couple of years back, I reported data corruption resulting from
> a change in kernel 3.16 which enabled hardware checksums in the r8152 driver.
> This was happening on an embedded system that was using a r8152 USB dongle.
>
> At the time,
I'm only posting to say I'm still waiting...
The error came up while I slept, and when I copied that log and looked
at it (yes, it WAS huge, just as you said), the timestamps at the
head/tail were much later than the journal logged times.
So I made a little script to monitor the journal kernel entr
On Sun, 6 Jan 2019, Paul Elder wrote:
> Implement the mechanism for optional explicit status stage for the MUSB
> driver. This allows a function driver to specify what to reply for the
> status stage. The functionality for an implicit status stage is
> retained.
>
> Signed-off-by: Paul Elder
> v
On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
Mark Lord
wrote:
..
>> There is even now a special hack in the upstream r8152.c to attempt to detect
>> a Dell TB16 dock and disable RX Aggregation in the driver to prevent such
>> issues.
>>
>> Well.. I have a WD15 doc
On 2019-01-06 4:13 p.m., Mark Lord wrote:
> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
> Mark Lord
> wrote:
> ..
>>> There is even now a special hack in the upstream r8152.c to attempt to
>>> detect
>>> a Dell TB16 dock and disable RX Aggregation in the driver t
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 880009987460..813673eee815 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -250,6 +250,10 @@ static int ci_hdrc_msm_probe(struct platform_device
>
Monday, January 07, 2019 5:17 AM
[...]
>> This is probably an xHC bug. A similar issue is fixed by commit 9da5a1092b13
>> ("xhci: Bad Ethernet performance plugged in ASM1042A host”).
>>
>>> I just got that exact message above, with the r8152 in my 1-day old WD15
>>> dock,
>>> with the TB16 "worka
> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>
> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
>> Mark Lord
>> wrote:
>> ..
There is even now a special hack in the upstream r8152.c to attempt to
detect
>>>
On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>
>
>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>
>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14
>>> PM, Mark Lord
>>> wrote:
>>> ..
> There is even now a special ha
From: M, Balaji
This fix enables USB role feature on intel commercial nuc
platform which is based on Kabylake chipset.
Signed-off-by: M, Balaji
---
drivers/usb/host/xhci-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index a9
Hi,
> On Dec 3, 2018, at 18:26, Kai-Heng Feng wrote:
>
> USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working
> after S3:
> [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_0302.bin
> [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110)
>
> After
> On Jan 7, 2019, at 12:13, Mark Lord wrote:
>
> On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>>
>>
>>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>>
>>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14
PM, Mar
On 2019-01-07 1:46 a.m., Kai Heng Feng wrote:
>
> Do you happen to use a Dell system? We can do some test here.
Yes. It is a Dell XPS 13 9360 i7-8550U notebook,
with the Dell WD15 USB-C dock.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
On Fri, 2019-01-04 at 10:10 -0600, Rob Herring wrote:
> On Thu, Jan 3, 2019 at 9:00 PM Min Guo wrote:
> >
> > On Thu, 2019-01-03 at 16:14 -0600, Rob Herring wrote:
> > > On Thu, Dec 27, 2018 at 03:34:23PM +0800, min@mediatek.com wrote:
> > > > From: Min Guo
> > > >
> > > > This adds support f
Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI
device
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0cad ProdID=9016 Rev=24.16
S: Manufacturer=Motorola Solutions, Inc.
S: Product=
22 matches
Mail list logo
