| 00:55.11 | *** join/#qi-hardware wildlander (~wild@unaffiliated/wildlander) |
| 01:44.24 | *** join/#qi-hardware pcercuei (~paul@12.206.185.66) |
| 01:46.57 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 02:24.34 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 02:53.48 | *** join/#qi-hardware archang (~archang@122.133.52.113.static.ximdns.com) |
| 05:57.20 | whitequark | DocScrutinizer05: you're almost right but you're being slightly too harsh |
| 05:57.20 | whitequark | well |
| 05:57.33 | whitequark | you CAN drill using an endmill, your plunge speed just has to be 1/10 of your cut speed |
| 05:57.40 | whitequark | that is what tool vendors recommend usually |
| 05:57.51 | whitequark | (1/10 not exact number, consult your tool vendor, etc) |
| 05:57.56 | whitequark | the thing is |
| 05:58.26 | whitequark | when you are pocketing, your tool is engaged 180° |
| 05:58.36 | whitequark | and when you are plunging, your tool is engaged 360° |
| 05:59.20 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 05:59.36 | whitequark | so you need to get higher speed, lower feed, or both. or you get tool deflection and frame stress. |
| 07:10.24 | DocScrutinizer05 | sorry, didn't mean to sound garsh |
| 07:51.28 | mth | larsc: in jz4740-battery.c, there is the following line: |
| 07:51.48 | mth | if (abs(voltage - jz_battery->voltage) < 50000) { ... (consider voltage changed) ... } |
| 07:52.31 | mth | is that there deliberately to filter out erroreous reads, or is it a mistake and should it have used ">" instead to avoid issuing of redundant updates? |
| 07:52.50 | larsc | should be a > |
| 07:52.59 | mth | ok |
| 07:53.09 | mth | also that line doesn't check for voltage containing an error code |
| 07:59.33 | mth | I made a patch; I'll submit it after 4.2 |
| 08:03.27 | larsc | thanks |
| 08:37.51 | *** join/#qi-hardware jwhitmore (~jwhitmore@host213-122-246-19.range213-122.btcentralplus.com) |
| 09:01.37 | mth | larsc: this is not your code, but if you have time, could you have a look at power_supply_check_supplies() in drivers/power/power_supply_core.c? |
| 09:01.52 | mth | the way psy->supplied_from is allocated makes no sense to me |
| 09:02.03 | *** join/#qi-hardware nicksydney (~quassel@63.085.dsl.syd.iprimus.net.au) |
| 09:02.09 | mth | I don't know if I haven't fully woken up or the code is entirely wrong |
| 09:03.04 | nicksydney | interested in decapping ? http://hackaday.com/2015/08/24/using-a-laser-cutter-to-decap-ics/ |
| 09:05.27 | larsc | mth: yeah, that looks a bit strange |
| 09:06.41 | mth | another problem I think is that __power_supply_populate_supplied_from() restarts at index 0 every time |
| 09:06.55 | mth | while starting at psy->num_supplies would make more sense |
| 09:08.14 | larsc | to be honest I can't see how that allocation scheme would work without crashing |
| 09:08.31 | larsc | (in case there is more than 1 supplier) |
| 09:08.42 | mth | maybe cases with more than 1 supplier are rare? |
| 09:08.48 | mth | although the example does list 2 suppliers |
| 09:09.50 | larsc | i is also always 0 in __power_supply_populate_supplied_from |
| 09:09.58 | larsc | regardless of the number of loop iterations |
| 09:10.11 | mth | yes, I wrote that a few liens ago ;) |
| 09:10.15 | mth | *lines |
| 09:11.03 | mth | well, there is an i++, it just starts from 0 every time the function is called |
| 09:11.39 | larsc | oh, overlooked that |
| 09:11.44 | larsc | it's well hidden |
| 09:12.11 | mth | yeah, plus it seems a bit out of place, since i-1 has to be used later to compensate for the early increase |
| 09:12.53 | mth | actually, it is not even correct; two separate counters are needed |
| 09:13.00 | larsc | yes |
| 09:13.44 | mth | eh, the np == epsy->of_node breaks from the loop |
| 09:15.07 | mth | what does that guard even test? |
| 09:16.01 | mth | hmm, I think this can get at most one match, maybe that's why no crashes have been detected |
| 09:16.11 | larsc | yes |
| 09:16.32 | larsc | well |
| 09:16.47 | larsc | it will crash if i > 1 |
| 09:17.02 | mth | ah yes |
| 09:17.04 | larsc | what the code does |
| 09:17.14 | larsc | is to iterate over all registered power supplies |
| 09:17.20 | larsc | class_for_each_device |
| 09:18.01 | larsc | than for each power supply it will iterate over the power-supplies node of the new supply |
| 09:18.25 | larsc | and check if the power supply (epsy) supplies the new one (psy) |
| 09:18.51 | larsc | so the iterating is actually correct |
| 09:19.52 | mth | the "while (np)" is redundant though, since for !np the loop has already been left |
| 09:21.16 | larsc | the code might have been easier to understand, if the loops had been nested the other way around |
| 09:21.40 | larsc | iterate over all power-supplies values and then call class_find_device for each |
| 09:21.59 | mth | yes |
| 09:22.41 | mth | that would also make the order of found supplies more predictable |
| 09:22.57 | mth | although I don't know if the order should carry any meaning |
| 09:26.36 | mth | maybe it tries to preserve order through the [i-1] assignment? |
| 09:27.16 | mth | but then there might be holes in the array if some supplies are not found |
| 09:27.54 | mth | and other code uses num_supplies as the upper bound for iteration, which wouldn't work then |
| 09:27.58 | mth | so that doesn't sound likely |
| 09:31.03 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 09:32.33 | mth | the "cnt - 1" in power_supply_check_supplies() is actually the number of found nodes, since cnt is increased prematurely there as well |
| 09:35.16 | mth | but even so, that array should be assigned directly to psy->supplied_from, I think, not to *psy->supplied_from |
| 09:40.56 | mth | larsc: what would be the best course of action? mail the author, or submit a patch for review? |
| 09:56.27 | larsc | both I guess |
| 10:04.12 | mth | hmm, could the existing power_supply_get_by_phandle() be used as part of the search? |
| 10:07.28 | larsc | yes |
| 10:13.34 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 10:24.22 | mth | what I'm trying to do is move the charger status implementation out of jz4770-battery (which is very similar to jz4740-battery and should be merged back into it at some point) |
| 10:24.35 | mth | is it safe to assume that all suppliers to a battery are chargers? |
| 11:05.09 | mth | hmm, multiple chargers is getting very complex, I'll probably just ignore any chargers beyond the first, since none of the existing use cases need more than one charger |
| 11:06.45 | *** join/#qi-hardware rozzin (rozzin@2600:3c00::f03c:91ff:fe56:7619) |
| 14:07.09 | *** join/#qi-hardware roh_ (~roh@yamato.hyte.de) |
| 16:33.27 | *** join/#qi-hardware rjeffries (~rjeffries@pool-74-111-228-106.snloca.dsl-w.verizon.net) |
| 16:40.59 | *** join/#qi-hardware pcercuei (~paul@50.246.116.68) |
| 18:02.27 | *** join/#qi-hardware Hex189 (~Hex@178.62.69.241) |
| 18:54.08 | *** join/#qi-hardware rjeffries (~rjeffries@pool-74-111-228-106.snloca.dsl-w.verizon.net) |
| 19:02.52 | DocScrutinizer05 | roh_: ping |
| 19:25.28 | roh_ | pong |
| 20:21.03 | *** join/#qi-hardware pcercuei (~paul@12.206.185.66) |
| 23:36.05 | *** join/#qi-hardware GonZo2000 (~GonZo@178.32.60.54) |
| 23:36.05 | *** join/#qi-hardware GonZo2000 (~GonZo@unaffiliated/gonzo2000) |
| 23:36.22 | *** join/#qi-hardware ysionneau (~fallen@ks3002254.kimsufi.com) |
| 23:48.35 | *** join/#qi-hardware wildlander (~wild@86.83-213-122.dynamic.clientes.euskaltel.es) |
| 23:48.45 | *** join/#qi-hardware wildlander (~wild@unaffiliated/wildlander) |