Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 10, 2012 at 3:41 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>
> It just isn't guaranteed that the subsystem callback won't do anything
> after driver->runtime_resume completion.  I agree that it isn't likely
> to happen.

In fact, the subsystem callback should make sure that don't happen, see
below comments on .runtime_resume:

 * @runtime_resume: Put the device into the fully active state in response to a
 *      wakeup event generated by hardware or at the request of software.  If
 *      necessary, put the device into the full-power state and restore its
 *      registers, so that it is fully operational.

So once driver->runtime_resume completes, the device should be fully operational
from the view of driver.

>
>> >> Firstly, introduce one extra pointer in device may increase memory
>> >> consume for device allocation,
>> >
>> > Yes, it does, which may or may not matter depending on the actual size of
>> > struct device and the CPU cache line size on the given machine, right?
>>
>> It may double memory allocation size in some cases. And it is very possible
>> since there are so many device objects in system.
>
> Numbers, please?  If you don't have them, it's just waving your hands.

It is easily observed and proved. Suppose sizeof(struct foo_dev) is 508bytes,
it will become 516bytes after your patch applies on 64bit arch, so
ksize(foo_dev_ptr)
will become 1024 and the memory consumption of the object is doubled.

>> I have explained it before, it is enough to keep the pointer read only
>> since driver can maintain its internal state in its specific device instance
>> (for example, usb_interface objects) and decide what to do in 'func'
>> for situations, right?
>
> Yes, it is.  I actually have a patch that does something similar (I'll post it
> shortly).

I have seen your patch which moves the 'func' from device into device_driver.
It is much better than before.

> Of course, it is based on the assumption that func() will always be the same
> pointer for the given driver, which doesn't seem to be proven, but perhaps
> it is sufficient.  At least I'm not aware of use cases where it wouldn't be.

Since you have moved 'func' into device_driver, and you still thought the
pointer can't be changed after it is set, so why not implement it as callback?

IMO, it is a bit weird to just store a function pointer data(not for
callback) in
driver object, but anyway, it is better than before, :-)

Thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux