On 30/08/2017 11:37, Mason wrote:
> On 30/08/2017 11:07, Ard Biesheuvel wrote:
>
>> Please don't forget to mention that this is quirky hardware that
>> depends on BROKEN because it multiplexes MMIO and config space
>> accesses in the same memory window without any locking whatsoever
>> (which wou
On 30/08/2017 11:06, Greg Kroah-Hartman wrote:
> On Wed, Aug 30, 2017 at 10:55:37AM +0200, Mason wrote:
>
>> On 30/08/2017 08:02, Greg Kroah-Hartman wrote:
>>
>>> To get back to the original issue here, the hardware seems to have died,
>>> the driver stops talking to it, and all is good. The "reg
On 31.08.2017 12:17, Mason wrote:
On 30/08/2017 11:37, Mason wrote:
On 30/08/2017 11:07, Ard Biesheuvel wrote:
Please don't forget to mention that this is quirky hardware that
depends on BROKEN because it multiplexes MMIO and config space
accesses in the same memory window without any locking
On 31.08.2017 12:39, Mason wrote:
On 30/08/2017 11:06, Greg Kroah-Hartman wrote:
On Wed, Aug 30, 2017 at 10:55:37AM +0200, Mason wrote:
On 30/08/2017 08:02, Greg Kroah-Hartman wrote:
To get back to the original issue here, the hardware seems to have died,
the driver stops talking to it, and
From: Thomas Gleixner
The tx_tasklet tasklet is used in invoke the hrtimer (task_timer) in
softirq context. This can be also achieved without the tasklet but with
CLOCK_MONOTONIC_SOFT as hrtimer base.
Signed-off-by: Thomas Gleixner
Signed-off-by: Anna-Maria Gleixner
Cc: Felipe Balbi
Cc: linux
From: Thomas Gleixner
The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in
softirq context. This can be also achieved without the tasklet but with
CLOCK_MONOTONIC_SOFT as hrtimer base.
Signed-off-by: Thomas Gleixner
Signed-off-by: Anna-Maria Gleixner
Cc: Oliver Neukum
Cc: Gre
From: Nicolas Ferre
The driver triggers actions on both edges of the vbus signal.
The former PIO controller was triggering IRQs on both falling and rising edges
by default. Newer PIO controller don't, so it's better to set it explicitly to
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING.
Without thi
The driver triggers actions on both edges of the vbus signal.
The former PIO controller was triggering IRQs on both falling and rising edges
by default. Newer PIO controller don't, so it's better to set it explicitly to
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING.
Without this patch we may trigger
On Thu, Aug 31, 2017 at 02:51:40PM +0200, Nicolas Ferre wrote:
> The driver triggers actions on both edges of the vbus signal.
>
> The former PIO controller was triggering IRQs on both falling and rising edges
> by default. Newer PIO controller don't, so it's better to set it explicitly to
> IRQF_
On Thu, Aug 31, 2017 at 12:23:46PM -, Anna-Maria Gleixner wrote:
> From: Thomas Gleixner
>
> The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in
> softirq context. This can be also achieved without the tasklet but with
> CLOCK_MONOTONIC_SOFT as hrtimer base.
>
> Signed-off-
Anna-Maria Gleixner writes:
> From: Thomas Gleixner
>
> The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in
> softirq context. This can be also achieved without the tasklet but with
> CLOCK_MONOTONIC_SOFT as hrtimer base.
>
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Ann
On Wed, Aug 23, 2017 at 07:14:33AM +0800, Chunfeng Yun wrote:
> Hi, Mathias
>
> On Wed, 2017-08-16 at 14:08 +0800, Chunfeng Yun wrote:
> > The xhci-mtk driver is a generic driver for MediaTek xHCI IP, add
> > a generic compatible to avoid confusion when support new SoCs but
> > use a compatible wi
On Thu, Aug 31, 2017 at 06:03:43PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 23, 2017 at 07:14:33AM +0800, Chunfeng Yun wrote:
> > Hi, Mathias
> >
> > On Wed, 2017-08-16 at 14:08 +0800, Chunfeng Yun wrote:
> > > The xhci-mtk driver is a generic driver for MediaTek xHCI IP, add
> > > a generic
Currently, xhci_plat is not set up properly when the parent device is an
ACPI node. The conditions that xhci_plat_probe should satisfy are
1. xhci_plat comes from firmware
2. xhci_plat is child of a device from firmware (dwc3-plat)
3. xhci_plat is grandchild of a pci device (dwc3-pci)
Case 2 is c
Servers were emitting failed handoff messages but were not
waiting the full 1 second as designated in section 4.22.1 of
the eXtensible Host Controller Interface specifications. The
handshake was using wrong units so calls were made with milliseconds
not microseconds. Comments referenced 5 seconds n
The .data assignment appears to be redundant to the WORK_STOP bit for
stopping the timer. Also, it appears this timer is entirely unused
as it is only ever started under #define VERBOSE, which is explicitly
undefined.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linu
With timer initialization made earlier at the start, there is no reason
to make del_timer_sync() calls conditionally, there by removing the
assignments and tests of the .data field.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Raviteja Garimella
Cc: Michal Nazarewicz
Cc: "Gustavo A. R. Silva"
I need to write an interface for an ov7251 sensor to the UVC (USB
Video Class). Never done this kind of work before (UVC and video
drivers) and hope someone could point me in the right direction.
1. Is it even possible to do?
2. I did find some drivers for OmniVision sensors in
http://elixir.free-
If xhci_disable_slot() returns success, a disable slot command
trb was queued in the command ring. The command completion
handler will free the virtual device data structure associated
with the slot. On the other hand, when xhci_disable_slot()
returns error, the invokers should take the responsibil
Hi Mathias,
Xhci driver handles USB transaction errors on transfer events,
but transaction errors are possible on address device command
completion events as well.
The xHCI specification (section 4.6.5) says: A USB Transaction
Error Completion Code for an Address Device Command may be due
to a St
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it checks
the corespoding virt-dev pointer and returns directly (w/o issuing
disable slot command) if it's null.
This is unnecessary and will cause problems in case where virt
Xhci driver handles USB transaction errors on transfer events,
but transaction errors are possible on address device command
completion events as well.
The xHCI specification (section 4.6.5) says: A USB Transaction
Error Completion Code for an Address Device Command may be due
to a Stall response
xhci->mutex was added in xhci_alloc_dev() to protect two race sources
(xhci->slot_id and xhci->addr_dev) by commit a00918d0521d ("usb: host:
xhci: add mutex for non-thread-safe data").
While xhci->slot_id has been discarded in commit c2d3d49bba08 ("usb:
xhci: move slot_id from xhci_hcd to xhci_co
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it returns
success when it sees a dead host. This is not the right way to go.
It should return error and let the invoker know that disable slot
command was failed due to a dead
xhci_disable_slot() allows the invoker to pass a command pointer
as paramenter. Otherwise, it will allocate one. This will cause
memory leak when a command structure was allocated inside of this
function while queuing command trb fails. Another problem comes up
when the invoker passed a command poi
Hi,
Jim Dickerson writes:
> Servers were emitting failed handoff messages but were not
> waiting the full 1 second as designated in section 4.22.1 of
> the eXtensible Host Controller Interface specifications. The
> handshake was using wrong units so calls were made with milliseconds
> not micros
26 matches
Mail list logo
