On 2019-08-23 8:43 a.m., Luis Chamberlain wrote:
On Fri, Aug 23, 2019 at 12:31:40PM +0200, Takashi Iwai wrote:
So, if any, we'd need put a mutex around the fallback loader code.
And, the mutex should be rather per device, not a global one.
Or we may trick it by appending the second parallel
On 2019-08-23 3:31 a.m., Takashi Iwai wrote:
On Tue, 20 Aug 2019 03:26:55 +0200,
Luis Chamberlain wrote:
On Mon, Aug 19, 2019 at 09:19:51AM -0700, Scott Branden wrote:
To be honest, I find the entire firmware code sloppy.
And that is after years of cleanup on my part. Try going back to v4.1
On Fri, Aug 23, 2019 at 12:31:40PM +0200, Takashi Iwai wrote:
> So, if any, we'd need put a mutex around the fallback loader code.
> And, the mutex should be rather per device, not a global one.
>
> Or we may trick it by appending the second parallel caller into the
> same wait queue, but the
On Tue, 20 Aug 2019 03:26:55 +0200,
Luis Chamberlain wrote:
>
> On Mon, Aug 19, 2019 at 09:19:51AM -0700, Scott Branden wrote:
> > To be honest, I find the entire firmware code sloppy.
>
> And that is after years of cleanup on my part. Try going back to v4.1
> for instance, check the code out
Hi Luis,
I'm glad you are a subject expert in this area.
Some more comments inline.
On 2019-08-19 6:26 p.m., Luis Chamberlain wrote:
On Mon, Aug 19, 2019 at 09:19:51AM -0700, Scott Branden wrote:
To be honest, I find the entire firmware code sloppy.
And that is after years of cleanup on my
On Mon, Aug 19, 2019 at 09:19:51AM -0700, Scott Branden wrote:
> To be honest, I find the entire firmware code sloppy.
And that is after years of cleanup on my part. Try going back to v4.1
for instance, check the code out then for an incredible horrific sight :)
> I don't think the
Hi Luis,
Thanks for the review.
I did not think this patch would be the final solution either
as indicated in the original cover letter and code comment.
Some comments inline.
On 2019-08-18 10:39 p.m., Luis Chamberlain wrote:
On Thu, Aug 15, 2019 at 05:09:45PM -0700, Scott Branden wrote:
On Thu, Aug 15, 2019 at 05:09:45PM -0700, Scott Branden wrote:
> A race condition exists between _request_firmware_prepare checking
> if firmware is assigned and firmware_fallback_sysfs creating a sysfs
> entry (kernel trace below). To avoid such condition add a mutex
> fw_lock_fallback to
8 matches
Mail list logo
