2015-08-24 00:40 pcercuei has quit [Ping timeout: 250 seconds]
2015-08-24 00:55 wildlander has joined #qi-hardware
2015-08-24 01:44 pcercuei has joined #qi-hardware
2015-08-24 01:46 fengling has joined #qi-hardware
2015-08-24 02:24 xiangfu has joined #qi-hardware
2015-08-24 02:53 archang has joined #qi-hardware
2015-08-24 03:41 pcercuei has quit [Ping timeout: 250 seconds]
2015-08-24 03:48 nicksydney has quit [Remote host closed the connection]
2015-08-24 05:03 lemonpepper24 has quit [Quit: Leaving]
2015-08-24 05:29 wildlander has quit [Quit: Saliendo]
2015-08-24 05:57 <whitequark> DocScrutinizer05: you're almost right but you're being slightly too harsh
2015-08-24 05:57 <whitequark> well
2015-08-24 05:57 <whitequark> you CAN drill using an endmill, your plunge speed just has to be 1/10 of your cut speed
2015-08-24 05:57 <whitequark> that is what tool vendors recommend usually
2015-08-24 05:57 <whitequark> (1/10 not exact number, consult your tool vendor, etc)
2015-08-24 05:57 <whitequark> the thing is
2015-08-24 05:58 xiangfu has quit [Ping timeout: 264 seconds]
2015-08-24 05:58 <whitequark> when you are pocketing, your tool is engaged 180°
2015-08-24 05:58 <whitequark> and when you are plunging, your tool is engaged 360°
2015-08-24 05:59 xiangfu has joined #qi-hardware
2015-08-24 05:59 <whitequark> so you need to get higher speed, lower feed, or both. or you get tool deflection and frame stress.
2015-08-24 06:02 apelete__ is now known as apelete
2015-08-24 07:10 <DocScrutinizer05> sorry, didn't mean to sound garsh
2015-08-24 07:51 <mth> larsc: in jz4740-battery.c, there is the following line:
2015-08-24 07:51 <mth> if (abs(voltage - jz_battery->voltage) < 50000) { ... (consider voltage changed) ... }
2015-08-24 07:52 <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?
2015-08-24 07:52 <larsc> should be a >
2015-08-24 07:52 <mth> ok
2015-08-24 07:53 <mth> also that line doesn't check for voltage containing an error code
2015-08-24 07:59 <mth> I made a patch; I'll submit it after 4.2
2015-08-24 08:03 <larsc> thanks
2015-08-24 08:37 jwhitmore has joined #qi-hardware
2015-08-24 08:43 jwhitmore has quit [Ping timeout: 240 seconds]
2015-08-24 09:01 <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?
2015-08-24 09:01 <mth> the way psy->supplied_from is allocated makes no sense to me
2015-08-24 09:02 nicksydney has joined #qi-hardware
2015-08-24 09:02 <mth> I don't know if I haven't fully woken up or the code is entirely wrong
2015-08-24 09:03 <nicksydney> interested in decapping ? http://hackaday.com/2015/08/24/using-a-laser-cutter-to-decap-ics/
2015-08-24 09:05 <larsc> mth: yeah, that looks a bit strange
2015-08-24 09:06 <mth> another problem I think is that __power_supply_populate_supplied_from() restarts at index 0 every time
2015-08-24 09:06 <mth> while starting at psy->num_supplies would make more sense
2015-08-24 09:08 <larsc> to be honest I can't see how that allocation scheme would work without crashing
2015-08-24 09:08 <larsc> (in case there is more than 1 supplier)
2015-08-24 09:08 <mth> maybe cases with more than 1 supplier are rare?
2015-08-24 09:08 <mth> although the example does list 2 suppliers
2015-08-24 09:09 <larsc> i is also always 0 in __power_supply_populate_supplied_from
2015-08-24 09:09 <larsc> regardless of the number of loop iterations
2015-08-24 09:10 <mth> yes, I wrote that a few liens ago ;)
2015-08-24 09:10 <mth> *lines
2015-08-24 09:11 <mth> well, there is an i++, it just starts from 0 every time the function is called
2015-08-24 09:11 <larsc> oh, overlooked that
2015-08-24 09:11 <larsc> it's well hidden
2015-08-24 09:12 <mth> yeah, plus it seems a bit out of place, since i-1 has to be used later to compensate for the early increase
2015-08-24 09:12 <mth> actually, it is not even correct; two separate counters are needed
2015-08-24 09:13 <larsc> yes
2015-08-24 09:13 <mth> eh, the np == epsy->of_node breaks from the loop
2015-08-24 09:15 <mth> what does that guard even test?
2015-08-24 09:16 <mth> hmm, I think this can get at most one match, maybe that's why no crashes have been detected
2015-08-24 09:16 <larsc> yes
2015-08-24 09:16 <larsc> well
2015-08-24 09:16 <larsc> it will crash if i > 1
2015-08-24 09:17 <mth> ah yes
2015-08-24 09:17 <larsc> what the code does
2015-08-24 09:17 <larsc> is to iterate over all registered power supplies
2015-08-24 09:17 <larsc> class_for_each_device
2015-08-24 09:18 <larsc> than for each power supply it will iterate over the power-supplies node of the new supply
2015-08-24 09:18 <larsc> and check if the power supply (epsy) supplies the new one (psy)
2015-08-24 09:18 <larsc> so the iterating is actually correct
2015-08-24 09:19 <mth> the "while (np)" is redundant though, since for !np the loop has already been left
2015-08-24 09:21 <larsc> the code might have been easier to understand, if the loops had been nested the other way around
2015-08-24 09:21 <larsc> iterate over all power-supplies values and then call class_find_device for each
2015-08-24 09:21 <mth> yes
2015-08-24 09:22 <mth> that would also make the order of found supplies more predictable
2015-08-24 09:22 <mth> although I don't know if the order should carry any meaning
2015-08-24 09:26 <mth> maybe it tries to preserve order through the [i-1] assignment?
2015-08-24 09:27 <mth> but then there might be holes in the array if some supplies are not found
2015-08-24 09:27 <mth> and other code uses num_supplies as the upper bound for iteration, which wouldn't work then
2015-08-24 09:27 <mth> so that doesn't sound likely
2015-08-24 09:28 xiangfu has quit [Ping timeout: 246 seconds]
2015-08-24 09:31 xiangfu has joined #qi-hardware
2015-08-24 09:32 <mth> the "cnt - 1" in power_supply_check_supplies() is actually the number of found nodes, since cnt is increased prematurely there as well
2015-08-24 09:35 <mth> but even so, that array should be assigned directly to psy->supplied_from, I think, not to *psy->supplied_from
2015-08-24 09:40 <mth> larsc: what would be the best course of action? mail the author, or submit a patch for review?
2015-08-24 09:56 <larsc> both I guess
2015-08-24 10:04 <mth> hmm, could the existing power_supply_get_by_phandle() be used as part of the search?
2015-08-24 10:07 <larsc> yes
2015-08-24 10:12 xiangfu has quit [Ping timeout: 272 seconds]
2015-08-24 10:13 xiangfu has joined #qi-hardware
2015-08-24 10:24 <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)
2015-08-24 10:24 <mth> is it safe to assume that all suppliers to a battery are chargers?
2015-08-24 10:42 xiangfu has quit [Remote host closed the connection]
2015-08-24 10:56 rozzin has quit [Ping timeout: 246 seconds]
2015-08-24 11:05 <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
2015-08-24 11:06 rozzin has joined #qi-hardware
2015-08-24 14:07 roh_ has joined #qi-hardware
2015-08-24 14:07 roh has quit [Ping timeout: 246 seconds]
2015-08-24 16:33 rjeffries has joined #qi-hardware
2015-08-24 16:40 pcercuei has joined #qi-hardware
2015-08-24 17:35 rjeffries has quit [Ping timeout: 256 seconds]
2015-08-24 18:02 Hex189 has joined #qi-hardware
2015-08-24 18:40 Hex189 has quit [Ping timeout: 264 seconds]
2015-08-24 18:54 rjeffries has joined #qi-hardware
2015-08-24 19:02 <DocScrutinizer05> roh_: ping
2015-08-24 19:22 rjeffries has quit [Ping timeout: 240 seconds]
2015-08-24 19:25 <roh_> pong
2015-08-24 19:25 roh_ is now known as roh
2015-08-24 19:50 pcercuei has quit [Ping timeout: 252 seconds]
2015-08-24 20:21 pcercuei has joined #qi-hardware
2015-08-24 23:35 ysionneau has quit [Ping timeout: 246 seconds]
2015-08-24 23:35 GonZo2000 has quit [Ping timeout: 246 seconds]
2015-08-24 23:36 GonZo2000 has joined #qi-hardware
2015-08-24 23:36 GonZo2000 has joined #qi-hardware
2015-08-24 23:36 ysionneau has joined #qi-hardware
2015-08-24 23:48 wildlander has joined #qi-hardware
2015-08-24 23:48 wildlander has quit [Changing host]
2015-08-24 23:48 wildlander has joined #qi-hardware