#qi-hardware IRC log for Monday, 2015-08-24

whitequarkDocScrutinizer05: you're almost right but you're being slightly too harsh05:57
whitequarkyou CAN drill using an endmill, your plunge speed just has to be 1/10 of your cut speed05:57
whitequarkthat is what tool vendors recommend usually05:57
whitequark(1/10 not exact number, consult your tool vendor, etc)05:57
whitequarkthe thing is05:57
whitequarkwhen you are pocketing, your tool is engaged 180°05:58
whitequarkand when you are plunging, your tool is engaged 360°05:58
whitequarkso you need to get higher speed, lower feed, or both. or you get tool deflection and frame stress.05:59
DocScrutinizer05sorry, didn't mean to sound garsh07:10
mthlarsc: in jz4740-battery.c, there is the following line:07:51
mthif (abs(voltage - jz_battery->voltage) < 50000) { ... (consider voltage changed) ... }07:51
mthis 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
larscshould be a >07:52
mthalso that line doesn't check for voltage containing an error code07:53
mthI made a patch; I'll submit it after 4.207:59
mthlarsc: 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
mththe way psy->supplied_from is allocated makes no sense to me09:01
mthI don't know if I haven't fully woken up or the code is entirely wrong09:02
nicksydneyinterested in decapping ? http://hackaday.com/2015/08/24/using-a-laser-cutter-to-decap-ics/09:03
larscmth: yeah, that looks a bit strange09:05
mthanother problem I think is that __power_supply_populate_supplied_from() restarts at index 0 every time09:06
mthwhile starting at psy->num_supplies would make more sense09:06
larscto be honest I can't see how that allocation scheme would work without crashing09:08
larsc(in case there is more than 1 supplier)09:08
mthmaybe cases with more than 1 supplier are rare?09:08
mthalthough the example does list 2 suppliers09:08
larsci is also always 0 in __power_supply_populate_supplied_from09:09
larscregardless of the number of loop iterations09:09
mthyes, I wrote that a few liens ago ;)09:10
mthwell, there is an i++, it just starts from 0 every time the function is called09:11
larscoh, overlooked that09:11
larscit's well hidden09:11
mthyeah, plus it seems a bit out of place, since i-1 has to be used later to compensate for the early increase09:12
mthactually, it is not even correct; two separate counters are needed09:12
mtheh, the np == epsy->of_node breaks from the loop09:13
mthwhat does that guard even test?09:15
mthhmm, I think this can get at most one match, maybe that's why no crashes have been detected09:16
larscit will crash if i > 109:16
mthah yes09:17
larscwhat the code does09:17
larscis to iterate over all registered power supplies09:17
larscthan for each power supply it will iterate over the power-supplies node of the new supply09:18
larscand check if the power supply (epsy) supplies the new one (psy)09:18
larscso the iterating is actually correct09:18
mththe "while (np)" is redundant though, since for !np the loop has already been left09:19
larscthe code might have been easier to understand, if the loops had been nested the other way around09:21
larsciterate over all power-supplies values and then call class_find_device for each09:21
mththat would also make the order of found supplies more predictable09:22
mthalthough I don't know if the order should carry any meaning09:22
mthmaybe it tries to preserve order through the [i-1] assignment?09:26
mthbut then there might be holes in the array if some supplies are not found09:27
mthand other code uses num_supplies as the upper bound for iteration, which wouldn't work then09:27
mthso that doesn't sound likely09:27
mththe "cnt - 1" in power_supply_check_supplies() is actually the number of found nodes, since cnt is increased prematurely there as well09:32
mthbut even so, that array should be assigned directly to psy->supplied_from, I think, not to *psy->supplied_from09:35
mthlarsc: what would be the best course of action? mail the author, or submit a patch for review?09:40
larscboth I guess09:56
mthhmm, could the existing power_supply_get_by_phandle() be used as part of the search?10:04
mthwhat 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
mthis it safe to assume that all suppliers to a battery are chargers?10:24
mthhmm, 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 charger11:05
DocScrutinizer05roh_: ping19:02
--- Tue Aug 25 201500:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!