{"push_id":697846478,"size":63,"distinct_size":63,"ref":"refs/heads/LG-STOCK-KK-106","head":"dc6842e56b8af88208489ac6fd0e78f8f5ce069b","before":"eaadc6acc76701e54043d1587ba278c33e4e5236","commits":[{"sha":"dd6880c2786ffc681ffa86242cb3e05e5ad35f55","author":{"email":"5b23f8226e886b22344fc642373ea657dd596b63@linux.vnet.ibm.com","name":"Srivatsa S. Bhat"},"message":"cpufreq: Preserve sysfs files across suspend/resume\n\nThe file permissions of cpufreq per-cpu sysfs files are not preserved\nacross suspend/resume because we internally go through the CPU\nHotplug path which reinitializes the file permissions on CPU online.\n\nBut the user is not supposed to know that we are using CPU hotplug\ninternally within suspend/resume (IOW, the kernel should not silently\nwreck the user-set file permissions across a suspend cycle).\nTherefore, we need to preserve the file permissions as they are\nacross suspend/resume.\n\nThe simplest way to achieve that is to just not touch the sysfs files\nat all - ie., just ignore the CPU hotplug notifications in the\nsuspend/resume path (_FROZEN) in the cpufreq hotplug callback.\n\nReported-by: Robert Jarzmik <robert.jarzmik@intel.com>\nReported-by: Durgadoss R <durgadoss.r@intel.com>\nSigned-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nAcked-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/dd6880c2786ffc681ffa86242cb3e05e5ad35f55"},{"sha":"dba93f0c8119d80d1ccbeefcff0deb2442b148c9","author":{"email":"aaf6fd97230863eae371b8b6c4c40693d5d84b30@bynet.co.il","name":"Dorimanx"},"message":"cpufreq: stats: do cpufreq_cpu_put() corresponding to cpufreq_cpu_get()\n\nIn cpufreq_stats_free_sysfs() we aren't balancing calls to\ncpufreq_cpu_get() with cpufreq_cpu_put(). This will never let us have\nref count to policy->kobj as zero.\n\nWe will get a hang if somehow cpufreq_driver_unregister() is called.\nAnd that can happen when we compile our driver as module and\ninsmod/rmmod it.\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nAcked-by: Amit Kucheria <amit.kucheria@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\n\nDorimanx Note. this is adapted commit. original is here in 3.10.y\nhttps://github.com/dorimanx/Dorimanx-LG-G2-D802-Kernel/commit/187da1d97f3a949b967274d7ee2f95d3a4f39251","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/dba93f0c8119d80d1ccbeefcff0deb2442b148c9"},{"sha":"34e9d7464387640448f59b9acaf760f3c361276e","author":{"email":"16a9a54ddf4259952e3c118c763138e83693d7fd@perches.com","name":"Joe Perches"},"message":"drivers: base: Convert dev_printk(KERN_<LEVEL> to dev_<level>(\n\ndev_<level> calls take less code than dev_printk(KERN_<LEVEL>\nand reducing object size is good.\n\nSigned-off-by: Joe Perches <joe@perches.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/34e9d7464387640448f59b9acaf760f3c361276e"},{"sha":"13c5d97bedd50e0f69a0abbaed35b9f0a4574926","author":{"email":"4645f7897fd33786a2ee1264d590b3c400559d85@linuxfoundation.org","name":"Greg Kroah-Hartman"},"message":"driver core: export subsys_virtual_register\n\nModules want to call this function, so it needs to be exported.\n\nReported-by: Daniel Mack <zonque@gmail.com>\nCc: Kay Sievers <kay@vrfy.org>\nCc: Tejun Heo <tj@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/13c5d97bedd50e0f69a0abbaed35b9f0a4574926"},{"sha":"6ddf110af5d05319f6b7ceef63177aac9098a4b9","author":{"email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.cz","name":"Michal Hocko"},"message":"device: separate all subsys mutexes\n\nca22e56d (driver-core: implement 'sysdev' functionality for regular\ndevices and buses) has introduced bus_register macro with a static\nkey to distinguish different subsys mutex classes.\n\nThis however doesn't work for different subsys which use a common\nregistering function. One example is subsys_system_register (and\nmce_device and cpu_device).\n\nIn the end this leads to the following lockdep splat:\n[  207.271924] ======================================================\n[  207.271932] [ INFO: possible circular locking dependency detected ]\n[  207.271942] 3.9.0-rc1-0.7-default+ #34 Not tainted\n[  207.271948] -------------------------------------------------------\n[  207.271957] bash/10493 is trying to acquire lock:\n[  207.271963]  (subsys mutex){+.+.+.}, at: [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0\n[  207.271987]\n[  207.271987] but task is already holding lock:\n[  207.271995]  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81046ccf>] cpu_hotplug_begin+0x2f/0x60\n[  207.272012]\n[  207.272012] which lock already depends on the new lock.\n[  207.272012]\n[  207.272023]\n[  207.272023] the existing dependency chain (in reverse order) is:\n[  207.272033]\n[  207.272033] -> #4 (cpu_hotplug.lock){+.+.+.}:\n[  207.272044]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120\n[  207.272056]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360\n[  207.272069]        [<ffffffff81046ba9>] get_online_cpus+0x29/0x40\n[  207.272082]        [<ffffffff81185210>] drain_all_stock+0x30/0x150\n[  207.272094]        [<ffffffff811853da>] mem_cgroup_reclaim+0xaa/0xe0\n[  207.272104]        [<ffffffff8118775e>] __mem_cgroup_try_charge+0x51e/0xcf0\n[  207.272114]        [<ffffffff81188486>] mem_cgroup_charge_common+0x36/0x60\n[  207.272125]        [<ffffffff811884da>] mem_cgroup_newpage_charge+0x2a/0x30\n[  207.272135]        [<ffffffff81150531>] do_wp_page+0x231/0x830\n[  207.272147]        [<ffffffff8115151e>] handle_pte_fault+0x19e/0x8d0\n[  207.272157]        [<ffffffff81151da8>] handle_mm_fault+0x158/0x1e0\n[  207.272166]        [<ffffffff814b6153>] do_page_fault+0x2a3/0x4e0\n[  207.272178]        [<ffffffff814b2578>] page_fault+0x28/0x30\n[  207.272189]\n[  207.272189] -> #3 (&mm->mmap_sem){++++++}:\n[  207.272199]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120\n[  207.272208]        [<ffffffff8114c5ad>] might_fault+0x6d/0x90\n[  207.272218]        [<ffffffff811a11e3>] filldir64+0xb3/0x120\n[  207.272229]        [<ffffffffa013fc19>] call_filldir+0x89/0x130 [ext3]\n[  207.272248]        [<ffffffffa0140377>] ext3_readdir+0x6b7/0x7e0 [ext3]\n[  207.272263]        [<ffffffff811a1519>] vfs_readdir+0xa9/0xc0\n[  207.272273]        [<ffffffff811a15cb>] sys_getdents64+0x9b/0x110\n[  207.272284]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b\n[  207.272296]\n[  207.272296] -> #2 (&type->i_mutex_dir_key#3){+.+.+.}:\n[  207.272309]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120\n[  207.272319]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360\n[  207.272329]        [<ffffffff8119c254>] link_path_walk+0x6f4/0x9a0\n[  207.272339]        [<ffffffff8119e7fa>] path_openat+0xba/0x470\n[  207.272349]        [<ffffffff8119ecf8>] do_filp_open+0x48/0xa0\n[  207.272358]        [<ffffffff8118d81c>] file_open_name+0xdc/0x110\n[  207.272369]        [<ffffffff8118d885>] filp_open+0x35/0x40\n[  207.272378]        [<ffffffff8135c76e>] _request_firmware+0x52e/0xb20\n[  207.272389]        [<ffffffff8135cdd6>] request_firmware+0x16/0x20\n[  207.272399]        [<ffffffffa03bdb91>] request_microcode_fw+0x61/0xd0 [microcode]\n[  207.272416]        [<ffffffffa03bd554>] microcode_init_cpu+0x104/0x150 [microcode]\n[  207.272431]        [<ffffffffa03bd61c>] mc_device_add+0x7c/0xb0 [microcode]\n[  207.272444]        [<ffffffff8134a419>] subsys_interface_register+0xc9/0x100\n[  207.272457]        [<ffffffffa04fc0f4>] 0xffffffffa04fc0f4\n[  207.272472]        [<ffffffff81000202>] do_one_initcall+0x42/0x180\n[  207.272485]        [<ffffffff810bbeff>] load_module+0x19df/0x1b70\n[  207.272499]        [<ffffffff810bc376>] sys_init_module+0xe6/0x130\n[  207.272511]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b\n[  207.272523]\n[  207.272523] -> #1 (umhelper_sem){++++.+}:\n[  207.272537]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120\n[  207.272548]        [<ffffffff814ae9c4>] down_read+0x34/0x50\n[  207.272559]        [<ffffffff81062bff>] usermodehelper_read_trylock+0x4f/0x100\n[  207.272575]        [<ffffffff8135c7dd>] _request_firmware+0x59d/0xb20\n[  207.272587]        [<ffffffff8135cdd6>] request_firmware+0x16/0x20\n[  207.272599]        [<ffffffffa03bdb91>] request_microcode_fw+0x61/0xd0 [microcode]\n[  207.272613]        [<ffffffffa03bd554>] microcode_init_cpu+0x104/0x150 [microcode]\n[  207.272627]        [<ffffffffa03bd61c>] mc_device_add+0x7c/0xb0 [microcode]\n[  207.272641]        [<ffffffff8134a419>] subsys_interface_register+0xc9/0x100\n[  207.272654]        [<ffffffffa04fc0f4>] 0xffffffffa04fc0f4\n[  207.272666]        [<ffffffff81000202>] do_one_initcall+0x42/0x180\n[  207.272678]        [<ffffffff810bbeff>] load_module+0x19df/0x1b70\n[  207.272690]        [<ffffffff810bc376>] sys_init_module+0xe6/0x130\n[  207.272702]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b\n[  207.272715]\n[  207.272715] -> #0 (subsys mutex){+.+.+.}:\n[  207.272729]        [<ffffffff810ae002>] __lock_acquire+0x13b2/0x15f0\n[  207.272740]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120\n[  207.272751]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360\n[  207.272763]        [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0\n[  207.272775]        [<ffffffff81349114>] device_del+0x134/0x1f0\n[  207.272786]        [<ffffffff813491f2>] device_unregister+0x22/0x60\n[  207.272798]        [<ffffffff814a24ea>] mce_cpu_callback+0x15e/0x1ad\n[  207.272812]        [<ffffffff814b6402>] notifier_call_chain+0x72/0x130\n[  207.272824]        [<ffffffff81073d6e>] __raw_notifier_call_chain+0xe/0x10\n[  207.272839]        [<ffffffff81498f76>] _cpu_down+0x1d6/0x350\n[  207.272851]        [<ffffffff81499130>] cpu_down+0x40/0x60\n[  207.272862]        [<ffffffff8149cc55>] store_online+0x75/0xe0\n[  207.272874]        [<ffffffff813474a0>] dev_attr_store+0x20/0x30\n[  207.272886]        [<ffffffff812090d9>] sysfs_write_file+0xd9/0x150\n[  207.272900]        [<ffffffff8118e10b>] vfs_write+0xcb/0x130\n[  207.272911]        [<ffffffff8118e924>] sys_write+0x64/0xa0\n[  207.272923]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b\n[  207.272936]\n[  207.272936] other info that might help us debug this:\n[  207.272936]\n[  207.272952] Chain exists of:\n[  207.272952]   subsys mutex --> &mm->mmap_sem --> cpu_hotplug.lock\n[  207.272952]\n[  207.272973]  Possible unsafe locking scenario:\n[  207.272973]\n[  207.272984]        CPU0                    CPU1\n[  207.272992]        ----                    ----\n[  207.273000]   lock(cpu_hotplug.lock);\n[  207.273009]                                lock(&mm->mmap_sem);\n[  207.273020]                                lock(cpu_hotplug.lock);\n[  207.273031]   lock(subsys mutex);\n[  207.273040]\n[  207.273040]  *** DEADLOCK ***\n[  207.273040]\n[  207.273055] 5 locks held by bash/10493:\n[  207.273062]  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81209049>] sysfs_write_file+0x49/0x150\n[  207.273080]  #1:  (s_active#150){.+.+.+}, at: [<ffffffff812090c2>] sysfs_write_file+0xc2/0x150\n[  207.273099]  #2:  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff81027557>] cpu_hotplug_driver_lock+0x17/0x20\n[  207.273121]  #3:  (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff8149911c>] cpu_down+0x2c/0x60\n[  207.273140]  #4:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81046ccf>] cpu_hotplug_begin+0x2f/0x60\n[  207.273158]\n[  207.273158] stack backtrace:\n[  207.273170] Pid: 10493, comm: bash Not tainted 3.9.0-rc1-0.7-default+ #34\n[  207.273180] Call Trace:\n[  207.273192]  [<ffffffff810ab373>] print_circular_bug+0x223/0x310\n[  207.273204]  [<ffffffff810ae002>] __lock_acquire+0x13b2/0x15f0\n[  207.273216]  [<ffffffff812086b0>] ? sysfs_hash_and_remove+0x60/0xc0\n[  207.273227]  [<ffffffff810ae329>] lock_acquire+0xe9/0x120\n[  207.273239]  [<ffffffff8134af27>] ? bus_remove_device+0x37/0x1c0\n[  207.273251]  [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360\n[  207.273263]  [<ffffffff8134af27>] ? bus_remove_device+0x37/0x1c0\n[  207.273274]  [<ffffffff812086b0>] ? sysfs_hash_and_remove+0x60/0xc0\n[  207.273286]  [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0\n[  207.273298]  [<ffffffff81349114>] device_del+0x134/0x1f0\n[  207.273309]  [<ffffffff813491f2>] device_unregister+0x22/0x60\n[  207.273321]  [<ffffffff814a24ea>] mce_cpu_callback+0x15e/0x1ad\n[  207.273332]  [<ffffffff814b6402>] notifier_call_chain+0x72/0x130\n[  207.273344]  [<ffffffff81073d6e>] __raw_notifier_call_chain+0xe/0x10\n[  207.273356]  [<ffffffff81498f76>] _cpu_down+0x1d6/0x350\n[  207.273368]  [<ffffffff81027557>] ? cpu_hotplug_driver_lock+0x17/0x20\n[  207.273380]  [<ffffffff81499130>] cpu_down+0x40/0x60\n[  207.273391]  [<ffffffff8149cc55>] store_online+0x75/0xe0\n[  207.273402]  [<ffffffff813474a0>] dev_attr_store+0x20/0x30\n[  207.273413]  [<ffffffff812090d9>] sysfs_write_file+0xd9/0x150\n[  207.273425]  [<ffffffff8118e10b>] vfs_write+0xcb/0x130\n[  207.273436]  [<ffffffff8118e924>] sys_write+0x64/0xa0\n[  207.273447]  [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b\n\nWhich reports a false possitive deadlock because it sees:\n1) load_module -> subsys_interface_register -> mc_deveice_add (*) -> subsys->p->mutex -> link_path_walk -> lookup_slow -> i_mutex\n2) sys_write -> _cpu_down -> cpu_hotplug_begin -> cpu_hotplug.lock -> mce_cpu_callback -> mce_device_remove(**) -> device_unregister -> bus_remove_device -> subsys mutex\n3) vfs_readdir -> i_mutex -> filldir64 -> might_fault -> might_lock_read(mmap_sem) -> page_fault -> mmap_sem -> drain_all_stock -> cpu_hotplug.lock\n\nbut\n1) takes cpu_subsys subsys (*) but 2) takes mce_device subsys (**) so\nthe deadlock is not possible AFAICS.\n\nThe fix is quite simple. We can pull the key inside bus_type structure\nbecause they are defined per device so the pointer will be unique as\nwell. bus_register doesn't need to be a macro anymore so change it\nto the inline. We could get rid of __bus_register as there is no other\ncaller but maybe somebody will want to use a different key so keep it\naround for now.\n\nReported-by: Li Zefan <lizefan@huawei.com>\nSigned-off-by: Michal Hocko <mhocko@suse.cz>\nSigned-off-by: Jiri Kosina <jkosina@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/6ddf110af5d05319f6b7ceef63177aac9098a4b9"},{"sha":"d87f8966059ade2db7f68fbab08903885fd69592","author":{"email":"6208e3c588e4690c7dfac5e95777d6a902c5fb27@virginia.edu","name":"Bill Pemberton"},"message":"driver core: remove CONFIG_HOTPLUG ifdefs\n\nRemove conditional code based on CONFIG_HOTPLUG being false.  It's\nalways on now in preparation of it going away as an option.\n\nSigned-off-by: Bill Pemberton <wfp5p@virginia.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/d87f8966059ade2db7f68fbab08903885fd69592"},{"sha":"f689c8b36fd8c0aafbc24766da621e4c01f56c95","author":{"email":"34be3ca399e9e73d80098c083a5b58614c3ca6da@linux.vnet.ibm.com","name":"Sebastian Ott"},"message":"driver core: move uevent call to driver_register\n\nDevice driver attribute groups are created after userspace is notified\nvia an add event. Fix this by moving the kobject_uevent call to\ndriver_register after the attribute groups are added.\n\nSigned-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/f689c8b36fd8c0aafbc24766da621e4c01f56c95"},{"sha":"c2c4e1f95b09e292f38b0978a9f42588c352fdc7","author":{"email":"a3b51ccb87d18302c1692defcfbf83319d1737eb@renesas.com","name":"Kuninori Morimoto"},"message":"driver core: fixup reversed deferred probe order\n\nIf driver requests probe deferral,\nit will be added to deferred_probe_pending_list\nby driver_deferred_probe_add(), but, it used list_add().\nBecause of that, deferred probe will be run as reversed order.\nThis patch uses list_add_tail(), and solved this issue.\n\nSigned-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/c2c4e1f95b09e292f38b0978a9f42588c352fdc7"},{"sha":"1601d04a9781a3e4a74ca5fb2dc6ba70b9dffacd","author":{"email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com","name":"Hans de Goede"},"message":"device-core: Ensure drvdata = NULL when no driver is bound\n\n1) drvdata is for a driver to store a pointer to driver specific data\n2) If no driver is bound, there is no driver specific data associated with\n   the device\n3) Thus logically drvdata should be NULL if no driver is bound.\n\nBut many drivers don't clear drvdata on device_release, or set drvdata\nearly on in probe and leave it set on probe error. Both of which results\nin a dangling pointer in drvdata.\n\nThis patch enforce for drvdata to be NULL after device_release or on probe\nfailure.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/1601d04a9781a3e4a74ca5fb2dc6ba70b9dffacd"},{"sha":"16df6174b5decbf48fb34e43d9193e0c2ca3008f","author":{"email":"b51b9a92386687a9ac927cebfa0f978adeb8cea5@opensource.wolfsonmicro.com","name":"Mark Brown"},"message":"driver core: Move deferred devices to the end of dpm_list before probing\n\nWhen deferred probe was originally added the idea was that devices which\ndefer their probes would move themselves to the end of dpm_list in order\nto try to keep the assumptions that we're making about the list being in\nroughly the order things should be suspended correct. However this hasn't\nbeen what's been happening and doing it requires a lot of duplicated code\nto do the moves.\n\nInstead take a simple, brute force solution and have the deferred probe\ncode push devices to the end of dpm_list before it retries the probe. This\ndoes mean we lock the dpm_list a bit more often but it's very simple and\nthe code shouldn't be a fast path. We do the move with the deferred mutex\ndropped since doing things with fewer locks held simultaneously seems like\na good idea.\n\nThis approach was most recently suggested by Grant Likely.\n\nSigned-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>\nAcked-by: Rafael J. Wysocki <rjw@sisk.pl>\nCc: Grant Likely <grant.likely@secretlab.ca>,\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/16df6174b5decbf48fb34e43d9193e0c2ca3008f"},{"sha":"6f462ac7d095c3fd4bbbced1bffae37e3eafb748","author":{"email":"a11f87183a953ab11f50fbafff689c5a7fa3506c@sisk.pl","name":"Rafael J. Wysocki"},"message":"PM / Runtime: Do not increment device usage counts before probing\n\nThe pm_runtime_get_noresume() calls before really_probe() and\nbefore executing __device_attach() for each driver on the\ndevice's bus cause problems to happen if probing fails and if the\ndriver has enabled runtime PM for the device in its .probe()\ncallback.  Namely, in that case, if the device has been resumed\nby the driver after enabling its runtime PM and if it turns out that\n.probe() should return an error, the driver is supposed to suspend\nthe device and disable its runtime PM before exiting .probe().\nHowever, because the device's runtime PM usage counter was\nincremented by the core before calling .probe(), the driver's attempt\nto suspend the device will not succeed and the device will remain in\nthe full-power state after the failing .probe() has returned.\n\nTo fix this issue, remove the pm_runtime_get_noresume() calls from\ndriver_probe_device() and from device_attach() and replace the\ncorresponding pm_runtime_put_sync() calls with pm_runtime_idle()\nto preserve the existing behavior (which is to check if the device\nis idle and to suspend it eventually in that case after probing).\n\nReported-and-tested-by: Kevin Hilman <khilman@ti.com>\nReviewed-by: Kevin Hilman <khilman@ti.com>\nSigned-off-by: Rafael J. Wysocki <rjw@sisk.pl>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/6f462ac7d095c3fd4bbbced1bffae37e3eafb748"},{"sha":"4a8e206309f47dde4ef65dff163a4e1851c9f7f2","author":{"email":"fe47b31f388f85ce6ddf64bf3a0cf6b46077d0e6@linaro.org","name":"Ulf Hansson"},"message":"PM / Runtime: Idle devices asynchronously after probe|release\n\nPutting devices into idle|suspend in a synchronous manner means we are\nwaiting for each device to become idle|suspended before the probe|release\nis fully done.\n\nThis patch switch to use the asynchronous runtime PM API:s instead and\nthus improves the parallelism since we can move on and handle the next\ndevice in queue in an earlier phase.\n\nSigned-off-by: Ulf Hansson <ulf.hansson@linaro.org>\nAcked-by: Kevin Hilman <khilman@linaro.org>\nAcked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nCc: Alan Stern <stern@rowland.harvard.edu>\nAcked-by: Linus Walleij <linus.walleij@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/4a8e206309f47dde4ef65dff163a4e1851c9f7f2"},{"sha":"1bce28ee68ff407d1186059ba8cf8a15b946df72","author":{"email":"27ffc44a8ec6a212fba98cfc3246c6ce8ab131e0@intel.com","name":"Rafael J. Wysocki"},"message":"PM / runtime: Use pm_runtime_put_sync() in __device_release_driver()\n\ncommit baab52ded242c35a2290e1fa82e0cc147d0d8c1a upstream.\n\nCommit fa180eb448fa (PM / Runtime: Idle devices asynchronously after\nprobe|release) modified __device_release_driver() to call\npm_runtime_put(dev) instead of pm_runtime_put_sync(dev) before\ndetaching the driver from the device.  However, that was a mistake,\nbecause pm_runtime_put(dev) causes rpm_idle() to be queued up and\nthe driver may be gone already when that function is executed.\nThat breaks the assumptions the drivers have the right to make\nabout the core's behavior on the basis of the existing documentation\nand actually causes problems to happen, so revert that part of\ncommit fa180eb448fa and restore the previous behavior of\n__device_release_driver().\n\nReported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>\nFixes: fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release)\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nAcked-by: Kevin Hilman <khilman@linaro.org>\nAcked-by: Ulf Hansson <ulf.hansson@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/1bce28ee68ff407d1186059ba8cf8a15b946df72"},{"sha":"bd5866eb589dc7023f8c90a632ac0390a5d35a08","author":{"email":"577f74ec3f2c8a155237d5ad42a70103d17f8313@codeaurora.org","name":"Vikram Mulukutla"},"message":"dd: Invoke one probe retry cycle after every initcall level\n\nDrivers that are registered at an initcall level may have to\nwait until late_init before the probe deferral mechanism can\nretry their probe functions. It is possible that their\ndependencies were resolved much earlier, in some cases even\nbefore the next initcall level. Invoke one probe retry cycle\nat every _sync initcall level, allowing these drivers to be\nprobed earlier.\n\nA real world example of how this change helps follows. On the\nMSM8974, there are 3 devices that need to be probed in order\nfor the display driver to be able to probe and bring up a\ndisplay panel. These are the gdsc_mdss (a regulator device), the\nmmsscc-dsi device (a display clock controller), and the\ndsipllcc device (a PLL controller). Here is a kernel log that\nshows these devices probing in the wrong order:\n\n[0.503253] mmsscc-dsi fd8c0000.qcom,mmsscc-dsi: Failed to get pixel source. -- [1]\n[0.505210] dsipllcc fd8c0000.qcom,dsipllcc: Failed to get MDSS GDSC         -- [2]\n[0.523264] gdsc_mdss: no parameters                                         -- [3]\n\nOnly gdsc_mdss successfully probed at 0.52 seconds. Now without\n_this_ change, the current probe deferral mechanism results in\nthe devices probing at or after late_init:\n\n[9.196006] dsipllcc fd8c0000.qcom,dsipllcc: Registered DSI PLL clocks.        -- [2]\n[9.357440] mmsscc-dsi fd8c0000.qcom,mmsscc-dsi: Registered MMSSCC DSI clocks. -- [1]\n\nThus the display can only be brought up after 9.35 seconds. However,\nby allowing a probe retry after each initcall level, this number\nreduces drastically:\n\n[0.608252] dsipllcc fd8c0000.qcom,dsipllcc: Registered DSI PLL clocks.       -- [2]\n[0.613758] mmsscc-dsi fd8c0000.qcom,mmsscc-dsi: Registered MMSSCC DSI clocks.-- [1]\n\nThus the display can be brought up just after 0.61 seconds.\n\nChange-Id: I83d8ac89e591e89e27934c0402449437b61b2124\nSigned-off-by: Vikram Mulukutla <markivx@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/bd5866eb589dc7023f8c90a632ac0390a5d35a08"},{"sha":"402df640004aeaacc5a59d13772c962c38f00a5a","author":{"email":"b51b9a92386687a9ac927cebfa0f978adeb8cea5@opensource.wolfsonmicro.com","name":"Mark Brown"},"message":"devres: Clarify documentation for devres_destroy()\n\nIt's not massively obvious (at least to me) that removing and freeing a\nresource does not involve calling the release function for the resource\nbut rather only removes the management of it. Make the documentation more\nexplicit.\n\nSigned-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/402df640004aeaacc5a59d13772c962c38f00a5a"},{"sha":"af7518c8893aecdd5623f04f2d6316aaf9bf6a03","author":{"email":"8d0fc11caeb4659419f0ba3104eb4a9d30848d42@canonical.com","name":"Ming Lei"},"message":"driver core: devres: introduce devres_for_each_res\n\nThis patch introduces one devres API of devres_for_each_res\nso that the device's driver can iterate each resource it has\ninterest in.\n\nThe firmware loader will use the API to get each firmware name\nfrom the device instance.\n\nSigned-off-by: Ming Lei <ming.lei@canonical.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/af7518c8893aecdd5623f04f2d6316aaf9bf6a03"},{"sha":"9a173d8b9494eebb657fa0ed9ab7f1e678a518de","author":{"email":"6b8646d310837fed93a129ed3c979b90c7f2674f@gmail.com","name":"Dmitry Torokhov"},"message":"devres: allow adding custom actions to the stack\n\nSometimes drivers need to execute one-off actions in their error handling\nor device teardown paths. An example would be toggling a GPIO line to\nreset the controlled device into predefined state.\n\nTo allow performing such actions when using managed resources let's allow\nadding them to stack/group of devres resources.\n\nAcked-by: Tejun Heo <tj@kernel.org>\nAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/9a173d8b9494eebb657fa0ed9ab7f1e678a518de"},{"sha":"1fd24c8b7c1989a92a1513eff42fd4b4a06a1119","author":{"email":"6f29df8e90a57f1ba61ffd63b0468c86bb6d3a99@xenotime.net","name":"Randy Dunlap"},"message":"driver core: fix dma-buf.c kernel-doc warnings\n\nFix kernel-doc warnings in dma-buf.c:\n\nWarning(drivers/base/dma-buf.c:305): No description found for parameter 'dmabuf'\nWarning(drivers/base/dma-buf.c:305): Excess function parameter 'dma_buf' description in 'dma_buf_begin_cpu_access'\nWarning(drivers/base/dma-buf.c:332): No description found for parameter 'dmabuf'\nWarning(drivers/base/dma-buf.c:332): Excess function parameter 'dma_buf' description in 'dma_buf_end_cpu_access'\nWarning(drivers/base/dma-buf.c:350): No description found for parameter 'dmabuf'\nWarning(drivers/base/dma-buf.c:350): Excess function parameter 'dma_buf' description in 'dma_buf_kmap_atomic'\nWarning(drivers/base/dma-buf.c:367): No description found for parameter 'dmabuf'\nWarning(drivers/base/dma-buf.c:367): Excess function parameter 'dma_buf' description in 'dma_buf_kunmap_atomic'\nWarning(drivers/base/dma-buf.c:385): No description found for parameter 'dmabuf'\nWarning(drivers/base/dma-buf.c:385): Excess function parameter 'dma_buf' description in 'dma_buf_kmap'\nWarning(drivers/base/dma-buf.c:402): No description found for parameter 'dmabuf'\nWarning(drivers/base/dma-buf.c:402): Excess function parameter 'dma_buf' description in 'dma_buf_kunmap'\n\nSigned-off-by: Randy Dunlap <rdunlap@xenotime.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/1fd24c8b7c1989a92a1513eff42fd4b4a06a1119"},{"sha":"42ac50be160ec4c2ba82f313b992b8d9c62cd853","author":{"email":"f2295d84e358395675bc8031be58672073ae065e@redhat.com","name":"Dave Airlie"},"message":"dma-buf: add vmap interface\n\nThe main requirement I have for this interface is for scanning out\nusing the USB gpu devices. Since these devices have to read the\nframebuffer on updates and linearly compress it, using kmaps\nis a major overhead for every update.\n\nv2: fix warn issues pointed out by Sylwester Nawrocki.\n\nv3: fix compile !CONFIG_DMA_SHARED_BUFFER and add _GPL for now\n\nSigned-off-by: Dave Airlie <airlied@redhat.com>\nReviewed-by: Rob Clark <rob.clark@linaro.org>\nSigned-off-by: Sumit Semwal <sumit.semwal@linaro.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/42ac50be160ec4c2ba82f313b992b8d9c62cd853"},{"sha":"c643bd348a174792095a9d52268d7edbc8632c33","author":{"email":"d6930da0d649c01d063dcca4d796c2ac2cbb68ba@ti.com","name":"Sumit Semwal"},"message":"dma-buf: minor documentation fixes.\n\nSome minor inline documentation fixes for gaps resulting from new patches.\n\nSigned-off-by: Sumit Semwal <sumit.semwal@ti.com>\nSigned-off-by: Sumit Semwal <sumit.semwal@linaro.org>","distinct":true,"url":"https://api.github.com/repos/yzzbz/Dorimanx-LG-G2-D802-Kernel/commits/c643bd348a174792095a9d52268d7edbc8632c33"}]}