On Tue, Oct 09, 2012 at 10:55:17PM +0800, Ming Lei wrote:
> On Tue, Oct 9, 2012 at 8:36 PM, Mark Brown
> > On Tue, Oct 09, 2012 at 08:02:18PM +0800, Ming Lei wrote:
> > It doesn't really help as the ABI is such that you can only have one
> Could you let me know where the ABI is?
It's defined by
On Tue, Oct 9, 2012 at 8:36 PM, Mark Brown
wrote:
> On Tue, Oct 09, 2012 at 08:02:18PM +0800, Ming Lei wrote:
>
>> If loading via user space, timeout or not depends on userspace,
>> at least udev won't timeout on non-existent firmware image.
>
> This may be a mdev or old udev thing... it's defini
On Tue, Oct 09, 2012 at 08:02:18PM +0800, Ming Lei wrote:
> If loading via user space, timeout or not depends on userspace,
> at least udev won't timeout on non-existent firmware image.
This may be a mdev or old udev thing... it's definitely prevelant.
> Also looks request_firmware_nowait() is
On Tue, Oct 9, 2012 at 3:52 PM, Mark Brown
wrote:
> The point is that there's some firmware which the driver wants to load
> but where it's happy to continue if the user didn't provide one and
> doesn't want to introduce needless delays.
OK, I got it, thank you for sharing the use case.
If load
On Tue, Oct 09, 2012 at 03:34:52PM +0800, Ming Lei wrote:
> Yes, I agree, and my question is only on what you mentioned:
> "it didn't want to load an optional image"
> maybe I misunderstood the above, never mind, :-)
> So one driver should suppose the firmware is there, and the
>
On Tue, Oct 9, 2012 at 3:13 PM, Mark Brown
wrote:
>> If so, I am wondering why the driver has to call request_firmware()?
>> Looks just bypassing request_firmware() is fine for the driver, doesn't it?
>
> A driver has no way to tell if the firmware is there or not without
> asking for it.
Yes, I
On Tue, Oct 09, 2012 at 03:05:30PM +0800, Ming Lei wrote:
> On Tue, Oct 9, 2012 at 12:19 PM, Mark Brown
> > It seems better to punt that decision to callers - for example, the case
> In fact, -ENOENT is returned to caller for non-direct loading situation,
> see_request_firmware_load().
> I under
On Tue, Oct 9, 2012 at 12:19 PM, Mark Brown
> It seems better to punt that decision to callers - for example, the case
In fact, -ENOENT is returned to caller for non-direct loading situation,
see_request_firmware_load().
I understand drivers(caller) may be cheated if a zero-length firmware
image
On Tue, Oct 09, 2012 at 06:56:02AM +0800, Ming Lei wrote:
> Considered that zero-length firmware image doesn't make sense for drivers
> (callers), maybe it is a insane firmware image, so how about treating it as a
> failure?
It seems better to punt that decision to callers - for example, the case
On Sat, Oct 6, 2012 at 1:05 AM, Mark Brown
wrote:
> vmalloc() will fail (very loudly) if we try to allocate zero bytes to
> read a zero byte file. Instead report that we successfully read in all
> zero bytes.
>
> It's not immediately obvious to me that this is better than returning an
> error but
10 matches
Mail list logo
