On Thu, 4 Oct 2018, Jia-Ju Bai wrote:
> > Why? Forcing all the report buffer to be limited to be non-sleeping
> > allocations just because of two drivers, looks like an overkill, and
> > actually calls for more issues (as GFP_ATOMIC is of course in principle
> > less likely to succeed).
>
>
On Thu, 4 Oct 2018, Jia-Ju Bai wrote:
> > Why? Forcing all the report buffer to be limited to be non-sleeping
> > allocations just because of two drivers, looks like an overkill, and
> > actually calls for more issues (as GFP_ATOMIC is of course in principle
> > less likely to succeed).
>
>
On 2018/9/30 3:20, Jiri Kosina wrote:
On Sat, 29 Sep 2018, Jia-Ju Bai wrote:
picolcd_send_and_wait (acquire a spinlock)
hid_hw_request
__hid_request
hid_alloc_report_buf(GFP_KERNEL)
picolcd_reset (acquire a spinlock)
hid_hw_request
__hid_request
On 2018/9/30 3:20, Jiri Kosina wrote:
On Sat, 29 Sep 2018, Jia-Ju Bai wrote:
picolcd_send_and_wait (acquire a spinlock)
hid_hw_request
__hid_request
hid_alloc_report_buf(GFP_KERNEL)
picolcd_reset (acquire a spinlock)
hid_hw_request
__hid_request
On Sat, 29 Sep 2018, Jia-Ju Bai wrote:
> >> picolcd_send_and_wait (acquire a spinlock)
> >>hid_hw_request
> >> __hid_request
> >>hid_alloc_report_buf(GFP_KERNEL)
> >>
> >> picolcd_reset (acquire a spinlock)
> >>hid_hw_request
> >> __hid_request
> >>
On Sat, 29 Sep 2018, Jia-Ju Bai wrote:
> >> picolcd_send_and_wait (acquire a spinlock)
> >>hid_hw_request
> >> __hid_request
> >>hid_alloc_report_buf(GFP_KERNEL)
> >>
> >> picolcd_reset (acquire a spinlock)
> >>hid_hw_request
> >> __hid_request
> >>
On 2018/9/24 17:26, Jiri Kosina wrote:
On Thu, 13 Sep 2018, Jia-Ju Bai wrote:
hid_alloc_report_buf() has to be called with GFP_ATOMIC in
__hid_request(), because there are the following callchains
leading to __hid_request() being an atomic context:
picolcd_send_and_wait (acquire a
On 2018/9/24 17:26, Jiri Kosina wrote:
On Thu, 13 Sep 2018, Jia-Ju Bai wrote:
hid_alloc_report_buf() has to be called with GFP_ATOMIC in
__hid_request(), because there are the following callchains
leading to __hid_request() being an atomic context:
picolcd_send_and_wait (acquire a
On Thu, 13 Sep 2018, Jia-Ju Bai wrote:
> hid_alloc_report_buf() has to be called with GFP_ATOMIC in
> __hid_request(), because there are the following callchains
> leading to __hid_request() being an atomic context:
>
> picolcd_send_and_wait (acquire a spinlock)
> hid_hw_request
>
On Thu, 13 Sep 2018, Jia-Ju Bai wrote:
> hid_alloc_report_buf() has to be called with GFP_ATOMIC in
> __hid_request(), because there are the following callchains
> leading to __hid_request() being an atomic context:
>
> picolcd_send_and_wait (acquire a spinlock)
> hid_hw_request
>
hid_alloc_report_buf() has to be called with GFP_ATOMIC in
__hid_request(), because there are the following callchains
leading to __hid_request() being an atomic context:
picolcd_send_and_wait (acquire a spinlock)
hid_hw_request
__hid_request
hid_alloc_report_buf(GFP_KERNEL)
hid_alloc_report_buf() has to be called with GFP_ATOMIC in
__hid_request(), because there are the following callchains
leading to __hid_request() being an atomic context:
picolcd_send_and_wait (acquire a spinlock)
hid_hw_request
__hid_request
hid_alloc_report_buf(GFP_KERNEL)
12 matches
Mail list logo
