[01:24] yo [01:24] When enabling a module, do you enable each of it's dependencies by hand? [01:24] because that sounds mental [01:25] ( for eg. you want a module B that depends on module A, do you go and enable A by hand to be able to enable B? ) [01:30] shadeslayer: Do you mean in the configs when building a kernel, or when inserting a module into the running kernel? [01:30] infinity: the former [01:30] I want to build a config from a tree, but want to alter some things afterwards, and apparently I can't because it's parent deps haven't been enabled, so on and so forth [01:31] shadeslayer: Are you using a friendly frontend like menuconfig, or just trying to hammer a CONFIG_ in .config and hope for the best? [01:32] infinity: I've tried the Qt config gui [01:32] and it doesn't let me check the boxes [01:32] Then I guess you've answered your question. :P [01:32] heh [01:32] well, is there a way to automatically enable deps :P [01:33] via make/ [01:34] make oldconfig tries to clean up messes you've made, but it may disable your mess rather than enabling deps. [01:34] It's not fool-proof. [08:38] shadeslayer, infinity, right it tends to make the config sane which often involves turning things off again, turning things on often involves figuring out the deps slowly and painfully === maxb_ is now known as maxb [15:08] Greetings, kernel team. Trying to hunt down information to try and wrap my head on something. Someone on Ask Ubuntu posted that they want to get "USB Charging When Powered Off" working. From Sony's documentation (their system is Sony), there's a way to enable it via Windows power management. However, when they follow a provided answer to try and enable it on Linux they don't have any luck. It's my understanding of hardware that this is [15:08] something handled at the hardware level, not the software level. [15:09] From -devel, a general discussion with dobey suggested that it may be some Sony proprietary stuff from Windows that edits hardware settings, but i'm just trying to cover the bases on this one. Is it my understanding that such a feature would be BIOS/Hardware controlled rather than something the kernel in Ubuntu could set? [15:10] (https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1461986 was filed on this too) [15:10] Launchpad bug 1461986 in linux-lts-utopic (Ubuntu) "can't change usb_charge attribute in /sys/devices/platform/sony-laptop" [Undecided,New] [19:45] Hi, is there anything the reporters should provide in order to move forward this bug: 1438039? [19:45] bug 1438039 in linux (Ubuntu) "Ubuntu14.04.1 kernel panics with enic driver throwing a NULL Pointer exception" [High,Triaged] https://launchpad.net/bugs/1438039 [21:10] teward, it is hard to know without someone who knows the bios chiming in to say how it is intended to work, as just interfering with the h/w is dangerous if you don't know what it is gonig to do [21:12] catbus1, that bug report seems pretty complete [21:13] apw: ok, there hasn't been any activity on that bug since 3/30. [21:13] catbus1, we get a lot of bugs, finding the ones which are well specified isn't easy [21:14] ok [21:16] catbus1, I'll take a look at that bug. Are you sure 4cfe878 is the fix for this bug? [21:17] catbus1, ok i've marked it up so if that fix comes to us via stable we will notice, it _might_ because it is a dave miller one, and he doesn't allow them to be marked for stable so it is impossible to know which he is intending to [21:19] jsalisbury: I am not the reporter. Is there any reason why you need confirmation? [21:19] apw: thanks [21:19] jsalisbury: I can ask Srini to double check. [21:20] catbus1, I tried to perform a cherry-pick of that commit and it looks like it will also need 5 other commits backported. [21:20] catbus1, that commit is in mainline as of 3.17, so Vivid should have it. [21:20] catbus1, is it possible to test the vivid backport kernel for trusty? [21:22] jsalisbury: Yes, Srini asked me if there is anything they can help testing with. [21:22] you will provide the kernel version and how to enable the vivid hwe kernel in trusty in the bug, as usual, right? [21:23] catbus1, correct. I'll update the bug [21:23] jsalisbury: thank you. [21:23] catbus1, np