Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-18 Thread Wolfram Sang
> > I'd prefer this file to be in the i2c realm. Maybe > > 'include/linux/i2c-sccb.h" or something. I will come back to this. > > And while at it, I think we also need a .c file, the functions (and > especially > sccb_read_byte()) should not be static inline. Before we discuss this, we should

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-15 Thread Laurent Pinchart
Hello, On Thursday, 14 June 2018 18:33:58 EEST Wolfram Sang wrote: > On Wed, Jun 13, 2018 at 12:34:46AM +0900, Akinobu Mita wrote: > > (This is 2nd version of SCCB helpers patch. After 1st version was > > submitted, I sent alternative patch titled "i2c: add I2C_M_FORCE_STOP". > > But it wasn't

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-14 Thread Wolfram Sang
> > It sounds tempting, yet I am concerned about regressions. From that > > point of view, it is safer to introduce i2c_lock_segment() and convert the > > users which would benefit from that. How many drivers would be affected? > > Right, there is also the aspect that changing a function like

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-14 Thread Peter Rosin
On 2018-06-14 17:41, Wolfram Sang wrote: > >> So, maybe the easier thing to do is change i2c_lock_adapter to only >> lock the segment, and then have the callers beneath drivers/i2c/ >> (plus the above mlx90614 driver) that really want to lock the root >> adapter instead of the segment adapter

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-14 Thread Wolfram Sang
> So, maybe the easier thing to do is change i2c_lock_adapter to only > lock the segment, and then have the callers beneath drivers/i2c/ > (plus the above mlx90614 driver) that really want to lock the root > adapter instead of the segment adapter call a new function named > i2c_lock_root (or

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-14 Thread Wolfram Sang
On Wed, Jun 13, 2018 at 12:34:46AM +0900, Akinobu Mita wrote: > (This is 2nd version of SCCB helpers patch. After 1st version was > submitted, I sent alternative patch titled "i2c: add I2C_M_FORCE_STOP". > But it wasn't accepted because it makes the I2C core code unreadable. > I couldn't find out

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-13 Thread Peter Rosin
On 2018-06-12 19:31, Peter Rosin wrote: > On 2018-06-12 17:34, Akinobu Mita wrote: >> (This is 2nd version of SCCB helpers patch. After 1st version was >> submitted, I sent alternative patch titled "i2c: add I2C_M_FORCE_STOP". >> But it wasn't accepted because it makes the I2C core code

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-12 Thread Peter Rosin
On 2018-06-12 17:34, Akinobu Mita wrote: > (This is 2nd version of SCCB helpers patch. After 1st version was > submitted, I sent alternative patch titled "i2c: add I2C_M_FORCE_STOP". > But it wasn't accepted because it makes the I2C core code unreadable. > I couldn't find out a way to untangle

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-12 Thread Sebastian Reichel
Hi, On Wed, Jun 13, 2018 at 12:34:46AM +0900, Akinobu Mita wrote: > (This is 2nd version of SCCB helpers patch. After 1st version was > submitted, I sent alternative patch titled "i2c: add I2C_M_FORCE_STOP". > But it wasn't accepted because it makes the I2C core code unreadable. > I couldn't

[RFC PATCH v2] media: i2c: add SCCB helpers

2018-06-12 Thread Akinobu Mita
(This is 2nd version of SCCB helpers patch. After 1st version was submitted, I sent alternative patch titled "i2c: add I2C_M_FORCE_STOP". But it wasn't accepted because it makes the I2C core code unreadable. I couldn't find out a way to untangle it, so I returned to the original approach.) This