On 02/08/11 09:32, Hennerich, Michael wrote: > Jonathan Cameron wrote on 2011-02-07: >> On 02/07/11 15:34, Hennerich, Michael wrote: >>> Jonathan Cameron wrote on 2011-02-05: >>>> This is very much the starting point for bashing the meter drivers >>>> into shape. For now I've just removed most of the unused code and >> stubs. >>> >>> Instead of removing the stubs - I would rather prefer implementing >> them. >> I agree in the ideal case. But even then, it is much easier to review >> a patch that adds this functionality from scratch than it is to review >> one that relies on large amounts of existing dead code. >>> But I think you're right this dead code is not going to be useful >>> either. >>> >>>> I have also cleaned up spi bus handling. I may well have gotten that >>>> bit wrong so please do take a look. In some cases this involved >>>> turning one transfer into two so as to clarify what the code was >>>> doing. This may cause issues if the spi bus drivers don't play the >>>> game properly or as if I got the conversion wrong. >>> >>> Looks right - but I had to double check with the datasheet. The SPI >>> write then read behavior is a bit undefined. In particular, what is >>> shifted out on the MOSI pin during the receive part. >>> >>> Some implementations send zero/one or repeat the last word in the shift >>> register, while others tristate MOSI. If the target slave device in >>> questions also listens on MOSI while it drives MISO, unpredicted >>> behavior my result. >> Strange, I thought this was defined as always sending zero if not >> provided. If not then I would suggest we point this inconsistency out >> to the spi guys and fix it up in those implementations that don't >> conform. Otherwise as you say, one needs to always specify the other >> direction just to make sure nothing weird happens. >> All my testing is on ancient pxa boards, so I know that they always >> send zeros and dump whatever is recieved. > > This behavior is implemented in the SPI Master Controller Drivers, and not in the SPI Bus Core. > I know in the past some machine dependant implementations did it wrong. > However looking at the drivers today they all (at least the ones I looked at) > send zero in case tx_buf is NULL. Good. In that case shall I send this set on to Greg? Might as well get the easy cleanups in place asap. .... -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
