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