Re: [PATCH i2c-tools-3.1] i2c-tools: add new tool 'i2ctransfer'

2017-07-07 Thread Jean Delvare
nch 3.1 which is a bug-fix only branch. If people want the newest shiny stuff they should use the master branch. And if it bothers them that there is no released version of it... well they may be right, and it suggests it's about time to push a first version of i2c-tools 4 out the door. -- Jean Delvare SUSE L3 Support

Re: [PATCH v2] i2c: algo-bit: add support for I2C_M_STOP

2017-06-22 Thread Jean Delvare
o debug outputs into one? > > > + bit_dbg(3, _adap->dev, > > + "emitting enforced stop/start > > condition\n"); > Go ahead, fine with me. -- Jean Delvare SUSE L3 Support

Re: [PATCH] i2c: algo-bit: add support for I2C_M_STOP

2017-06-22 Thread Jean Delvare
lopers would be doing that if they didn't need it. -- Jean Delvare SUSE L3 Support

[PATCH v2] i2c: algo-bit: add support for I2C_M_STOP

2017-06-21 Thread Jean Delvare
Support for enforced STOPs will allow us to use SCCB compatible devices. Based on a preliminary patch by Wolfram Sang. Signed-off-by: Jean Delvare <jdelv...@suse.de> Tested-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Changes since v1: * Simplify logic drivers/i2c/al

Re: [PATCH] i2c: algo-bit: add support for I2C_M_STOP

2017-06-21 Thread Jean Delvare
bit_dbg(3, _adap->dev, > > + "emitting repeated start condition\n"); > > i2c_repstart(adap); > > } > > ret = bit_doAddress(i2c_adap, pmsg); > > A lot better! I like it very much. And also > > Tested-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > > Do you want to cook up a patch or shall I? I'd just need a SoB then. I'll send a proper patch shortly. > Thanks for the improvement! You're welcome. -- Jean Delvare SUSE L3 Support

Re: [PATCH] i2c: algo-bit: add support for I2C_M_STOP

2017-06-19 Thread Jean Delvare
"emitting start condition\n"); + i2c_start(adap); + } + + bit_dbg(3, _adap->dev, + "emitting repeated start condition\n"); i2c_repstart(adap); } ret = bit_doAddress(i2c_adap, pmsg); -- Jean Delvare SUSE L3 Support

Re: [RFC] i2c-stub: make it usable with DT when booting

2017-05-18 Thread Jean Delvare
am or if we want to stay module-only? Also, the binding should really > be marked as "development only". Or is it better to keep it as a separate > patch to keep the binding un-official? Code looks sane, but I can't comment on the bindings side of things as this isn't my area. -- Jean Delvare SUSE L3 Support

Re: [PATCH 2/2] i2c: stub: use pr_fmt

2017-05-18 Thread Jean Delvare
* Allocate memory for all chips at once */ > stub_chips_nr = i; > stub_chips = kcalloc(stub_chips_nr, sizeof(struct stub_chip), > GFP_KERNEL); > - if (!stub_chips) { > - pr_err("i2c-stub: Out of memory\n"); > + if (!stub_chips) > return -ENOMEM; > - } > + > for (i = 0; i < stub_chips_nr; i++) { > INIT_LIST_HEAD(_chips[i].smbus_blocks); > Looks good to me. Reviewed-by: Jean Delvare <jdelv...@suse.de> -- Jean Delvare SUSE L3 Support

Re: [PATCH 1/2] i2c: stub: move module_init/exit annotations to the proper place

2017-05-18 Thread Jean Delvare
quot;); > MODULE_LICENSE("GPL"); > - > -module_init(i2c_stub_init); > -module_exit(i2c_stub_exit); I'm not sure on what you base your claim that this is the "proper place". checkpatch doesn't complain about either, and if anything, the original style (module_init/exit) at end of file seems a lot more popular through the kernel tree. -- Jean Delvare SUSE L3 Support