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
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
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,
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
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 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 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 understand
On Tue, Oct 9, 2012 at 3:13 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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:52 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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 8:36 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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 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
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
On Sat, Oct 6, 2012 at 1:05 AM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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
I
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 it seems better to punt the decision about that to the caller
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 it seems better to punt the decision about that to the caller
22 matches
Mail list logo
