Re: [I2C] informations + advice about messages handling
Hi Jean, Le 24/05/2013 14:20, Jean Delvare a écrit : On Fri, 24 May 2013 11:52:54 +0200, Mylene Josserand wrote: - an audio codec tlv320aic3204 : There is a driver for this device but for some reasons, we did not use it. Did not find a SMBus compliant in its datasheet. The tlv320aic32x4 driver uses i2c_master_send, which is a shortcut to i2c_transfer. However it seems to only send 2 bytes on the bus at once, the same could be achieved with i2c_smbus_write_byte_data if needed. Okay, thanks to have looked at it ! For completeness: a device might use transactions which are compliant with SMBus without being formally SMBus-compliant, because SMBus has more constraints than just transaction types (I kept things simple originally to not confuse you.) This may explain why it isn't mentioned in the datasheet. Or just because the manufacturer did not care because they target fully I2C-capable systems anyway. What you have to look at is the transaction types. They are usually described in the datasheet. Then compare with either the SMBus specification or http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/smbus-protocol and if they match then you can use the i2c_smbus_*() calls. I have checked the PIC18F24201 according to your advice and, of what I have seen, it can handle the SMBus protocol. Thank you for the explanation and trying to keep it simple for me :) -- Mylène JOSSERAND ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
File System Implementation
Hi, I was implementing a file system and ran into the following problem. I wanted to replicate the super block data in order to recover from occasional Hard disk failures (bit rot problem etc.). While replicating was easy i could not find a way to detect the errors in the first place. Any ideas and explanation will be help full. -- With Regards Dibyayan Chakraborty ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: File System Implementation
Historically filesystem designers knew what legal values of the various parameters were and they simply looked for legal values. If they found any illegal values, they reset them to a legal value. In many cases, that missed bit-rot situations they wanted to find, so with many modern filesystems, they add a CRC field to the main datastructures, then do a CRC verification as appropriate. XFS is right now in the middle of getting a whole bunch of CRC functionality added. I don't know if it is on the generation side, or just on the verification side. A quick google found this overview email to a patch series. The series may have been posted again since then. http://comments.gmane.org/gmane.comp.file-systems.xfs.general/51575 Notice there are links to the 3 previous overview emails. Go back and read those, they may provide more background. Greg On Wed, May 29, 2013 at 10:20 AM, Dibyayan Chakraborty dib.cool...@gmail.com wrote: Hi, I was implementing a file system and ran into the following problem. I wanted to replicate the super block data in order to recover from occasional Hard disk failures (bit rot problem etc.). While replicating was easy i could not find a way to detect the errors in the first place. Any ideas and explanation will be help full. -- With Regards Dibyayan Chakraborty ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
