-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 14.07.2016 um 11:58 schrieb Wolfram Sang: > >> It's available here: >> >> https://github.com/ianka/w1_ds28e17 > > You need to send patches to get anything reviewed. > Is there a special procedure to follow to have those three diffs queued? Because Kconfig.diff, Makefile.diff and w1.diff are in that archive and the other diff can be easily obtained: $ diff -u /dev/null w1_ds28e17.c >w1_ds28e17.diff >> I've already sent a mail to Evgeniy Polyakov, maintainer of the >> W1 subsystem and Wolfram Sang, maintainer of the I2C subsystem >> but got no reply. Maybe due to holiday season. > > For my case, I am just extremly busy. Have a look for the pending > patches for I2C here: > > http://patchwork.ozlabs.org/project/linux-i2c/list/ > Uh! Understood. > Please also note, that a maintainer is not the only reviewer for a > subsystem, the whole list is. You can try there to get people > attracted to your patch. If you count on me, expect a delay of > weeks. > Oh, I haven't expected a review, just a ping "have noticed, please follow the procedure as follows." As I'm not familiar with the procedures. As for sending the information to you instead of the list, the MAINTAINERS file wasn't clear to me about this. And for the w1 subsystem, where this driver is also relevant to, there isn't a list at all. It's not clear to me who's in charge of a driver which touches both subsystems. >> I also have a question/feature request for the i2c subsystem. >> The DS28E17 can support I2C_M_STOP, which allows to combine >> write/read into a single transaction for slaves which need the >> intermediate stop condition – as the DS7505 from the evaluation >> board. Using I2C_M_STOP > > It cannot do repeated start? > The datasheet says it can at least for a write to the pointer byte followed by a read but it doesn't seem to work. - From my tests, it doesn't work, or it least it doesn't work the way the ds28e17 bus master does the repeated start. >> instead of splitting the transaction into two would save some >> overhead on the Onewire bus (8 bytes at 15kBaud == 4ms, of >> busy-looping when Onewire is bitbanged.) > >> What's the right way to handle this on the I2C driver side? Could >> we have a I2C_FUNC_STOP as we have a I2C_FUNC_NOSTART? > > We can factor it out like I2C_FUNC_NOSTART when it is proven that > it really is needed. > I will check it again. Kind regards Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAleHi1IACgkQzGZqmZvWQdm4oACfYOySD0I7LYljZxD/UYfNHjCy 0S4Amwdj0ctB3wi6qJFoHuz0JweYV1eW =ifHt -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
