* Tero Kristo [180619 12:13]:
>
> TI SoC arm64 PM is done via genpd attached to each domain, which in turn
> passes control messages to the PM firmware when transitions happen. See
> drivers/soc/ti_sci_pm_domains.c for details.
>
> Not quite sure about the discussion following later, but there
The USB completion callback does not disable interrupts while acquiring
the ->lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be
The USB completion callback does not disable interrupts while acquiring
the ->lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be
Using usb_fill_int_urb() helps to find code which initializes an
URB. A grep for members of the struct (like ->complete) reveal lots
of other things, too.
data_ep_set_params() additionally sets urb->transfer_buffer_length which
was not the case earlier.
data_ep_set_params() and
Using usb_fill_int_urb() helps to find code which initializes an
URB. A grep for members of the struct (like ->complete) reveal lots
of other things, too.
I'm keeping the transfer-length initialisation in
usX2Y_usbpcm_urbs_start() because I am not certain if this does not
change over time.
Cc:
From: John Ogness
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The
Using usb_fill_int_urb() helps to find code which initializes an
URB. A grep for members of the struct (like ->complete) reveal lots
of other things, too.
Cc: Daniel Mack
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Signed-off-by: Sebastian Andrzej Siewior
---
sound/usb/caiaq/audio.c | 23
This series is mostly about using _irqsave() primitives in the
completion callback in order to get rid of local_irq_save() in
__usb_hcd_giveback_urb(). While at it, I also tried to move drivers to
use usb_fill_int_urb() otherwise it is hard find users of a certain API.
Sebastian
--
To
Using usb_fill_int_urb() helps to find code which initializes an
URB. A grep for members of the struct (like ->complete) reveal lots
of other things, too.
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Clemens Ladisch
Signed-off-by: Sebastian Andrzej Siewior
---
sound/usb/misc/ua101.c | 10
Using usb_fill_int_urb() helps to find code which initializes an
URB. A grep for members of the struct (like ->complete) reveal lots
of other things, too.
The "&& !(*purb)->transfer_buffer" check has been removed because the
URB has been freshly allocated a few lines above so ->transfer_buffer
Using usb_fill_int_urb() helps to find code which initializes an
URB. A grep for members of the struct (like ->complete) reveal lots
of other things, too.
Data pointer & size is filled out later so they are not considered.
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Signed-off-by: Sebastian Andrzej
From: John Ogness
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The
Using usb_fill_int_urb() helps to find code which initializes an
URB. A grep for members of the struct (like ->complete) reveal lots
of other things, too.
usb6fire_comm_init_urb() passes no transfer length.
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Signed-off-by: Sebastian Andrzej Siewior
---
On Do, 2018-06-14 at 18:36 +0200, Sebastian Andrzej Siewior wrote:
> In the code path
> __usb_hcd_giveback_urb()
> -> wdm_in_callback()
>-> service_outstanding_interrupt()
>
> The function service_outstanding_interrupt() will unconditionally enable
> interrupts during unlock and invoke
Hi Felipe,
If there is no objections, can we please pull this patch? It fixes
kernel panic for us (scheduling in atomic context).
Thanks!
On 14 June 2018 at 16:23, Sam Protsenko wrote:
> + Roger Quadros
> + Praneeth Bajjuri
>
> Tested-by: Sam Protsenko
>
> I've tested it on X15 board (DWC3
On Tue, Jun 19, 2018 at 02:32:11PM +0200, Loic Poulain wrote:
> Hi Johan, Srini,
>
> On 18 June 2018 at 11:47, Srinivas Kandagatla
> wrote:
> > On 18/06/18 09:46, Johan Hovold wrote:
> >> I'm not necessarily against the idea, but nvmem core needs to be fixed
> >> so that it can handle
Good Day;
Dear Respectful One,
I am SALINAS ROMANS from France. Please go through below my mail and
see if you can Assist for Our mutual benefit, My late Father was a
serving director of the Cocoa exporting board in lvory coast until his
death.
He died in motor accident one week after his trip
Hi Johan, Srini,
On 18 June 2018 at 11:47, Srinivas Kandagatla
wrote:
>
>
> On 18/06/18 09:46, Johan Hovold wrote:
>>
>> On Thu, Jun 14, 2018 at 10:08:46PM +0200, Loic Poulain wrote:
>>>
>>> Most of FTDI's devices have an EEPROM which records FTDI devices
>>> configuration setting (e.g. the VID,
On 19/06/18 11:18, Felipe Balbi wrote:
Hi,
Roger Quadros writes:
I suggest merging this fix for 4.18-rc, and then Roger can rework the
driver so that it works also on OMAP.
omap has its own glue layer for several reasons. If you're talking about
Keystone devices, then okay, I understand.
Hi,
Roger Quadros writes:
>>> I suggest merging this fix for 4.18-rc, and then Roger can rework the
>>> driver so that it works also on OMAP.
>>
>> omap has its own glue layer for several reasons. If you're talking about
>> Keystone devices, then okay, I understand. But in
On 12.06.2018 00:10, Ajay Gupta wrote:
Some controllers take almost 55ms to complete controller
restore state (CRS).
There is no timeout limit mentioned in xhci specification so
fixing the issue by increasing the timeout limit to 100ms
Signed-off-by: Ajay Gupta
Signed-off-by: Nagaraj Annaiah
21 matches
Mail list logo
