Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On 05/08/2018 11:32 AM, Wolfram Sang wrote: Grygorii, thanks a lot for your input. Much appreciated! That would be great, but note: 1) only i2c_transfer() operations are locked, so if driver is doing i2c_transfer(1) i2c_transfer(2) <- suspend in the middle <- suspend in between

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On 05/08/2018 11:32 AM, Wolfram Sang wrote: Grygorii, thanks a lot for your input. Much appreciated! That would be great, but note: 1) only i2c_transfer() operations are locked, so if driver is doing i2c_transfer(1) i2c_transfer(2) <- suspend in the middle <- suspend in between

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On Sat, May 05, 2018 at 10:32:55AM +0200, Wolfram Sang wrote: > > OTOH it does mean we might not notice things happening later than they > > should so it's not 100% clear... > What do you mean here? If someone is doing I/O later than they should currently we'll notice as they try to do

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On Sat, May 05, 2018 at 10:32:55AM +0200, Wolfram Sang wrote: > > OTOH it does mean we might not notice things happening later than they > > should so it's not 100% clear... > What do you mean here? If someone is doing I/O later than they should currently we'll notice as they try to do

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On 2018-05-08 18:32, Wolfram Sang wrote: > Grygorii, > > thanks a lot for your input. Much appreciated! > >> That would be great, but note: >> 1) only i2c_transfer() operations are locked, so if driver is doing >> i2c_transfer(1) >> i2c_transfer(2) <- suspend in the middle >> <- suspend in

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On 2018-05-08 18:32, Wolfram Sang wrote: > Grygorii, > > thanks a lot for your input. Much appreciated! > >> That would be great, but note: >> 1) only i2c_transfer() operations are locked, so if driver is doing >> i2c_transfer(1) >> i2c_transfer(2) <- suspend in the middle >> <- suspend in

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

Grygorii, thanks a lot for your input. Much appreciated! > That would be great, but note: > 1) only i2c_transfer() operations are locked, so if driver is doing > i2c_transfer(1) > i2c_transfer(2) <- suspend in the middle > <- suspend in between > i2c_transfer(3) > It will not help. Will it not

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

Grygorii, thanks a lot for your input. Much appreciated! > That would be great, but note: > 1) only i2c_transfer() operations are locked, so if driver is doing > i2c_transfer(1) > i2c_transfer(2) <- suspend in the middle > <- suspend in between > i2c_transfer(3) > It will not help. Will it not

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On 05/04/2018 07:24 AM, Wolfram Sang wrote: > Hi Grygorii, > > thanks for stepping in. I kept thinking about better I2C core support > for such situations and the more input the better. > >> And you have to fix it (touch screen) - not your i2c driver. Otherwise, you >> can get >> situation

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On 05/04/2018 07:24 AM, Wolfram Sang wrote: > Hi Grygorii, > > thanks for stepping in. I kept thinking about better I2C core support > for such situations and the more input the better. > >> And you have to fix it (touch screen) - not your i2c driver. Otherwise, you >> can get >> situation

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

Hi Mark, > > And maybe this could be used here, too? Introduce this flag for very > > late/early messages. If they have it, messages are even sent in > > suspend_noirq() phase with the master_xfer_irqless() callback, otherwise > > we will have the WARNing printed out. > > It feels like it'd be

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

Hi Mark, > > And maybe this could be used here, too? Introduce this flag for very > > late/early messages. If they have it, messages are even sent in > > suspend_noirq() phase with the master_xfer_irqless() callback, otherwise > > we will have the WARNing printed out. > > It feels like it'd be

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On Fri, May 04, 2018 at 02:24:47PM +0200, Wolfram Sang wrote: > To handle that, I imagined an additional adapter callback like > 'master_xfer_irqless' to be used for such special I2C messages. These > kind of special messages could be tagged with a new I2C_M_something > flag. > And maybe this

Re: I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

On Fri, May 04, 2018 at 02:24:47PM +0200, Wolfram Sang wrote: > To handle that, I imagined an additional adapter callback like > 'master_xfer_irqless' to be used for such special I2C messages. These > kind of special messages could be tagged with a new I2C_M_something > flag. > And maybe this

I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

Hi Grygorii, thanks for stepping in. I kept thinking about better I2C core support for such situations and the more input the better. > And you have to fix it (touch screen) - not your i2c driver. Otherwise, you > can get > situation when set of I2C transfers (executed from some >

I2C PM overhaul needed? (Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called)

Hi Grygorii, thanks for stepping in. I kept thinking about better I2C core support for such situations and the more input the better. > And you have to fix it (touch screen) - not your i2c driver. Otherwise, you > can get > situation when set of I2C transfers (executed from some >

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On 05/02/2018 12:48 AM, Baolin Wang wrote: > On 2 May 2018 at 13:23, Wolfram Sang wrote: >> We should maybe handle this in the core somewhen, though. Or? >>> >>> Thanks. Yes, It will more helpful if we can handle this in the i2c core. >> >> To understand the issue

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On 05/02/2018 12:48 AM, Baolin Wang wrote: > On 2 May 2018 at 13:23, Wolfram Sang wrote: >> We should maybe handle this in the core somewhen, though. Or? >>> >>> Thanks. Yes, It will more helpful if we can handle this in the i2c core. >> >> To understand the issue better: which kind of

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On 2 May 2018 at 13:23, Wolfram Sang wrote: > >> > We should maybe handle this in the core somewhen, though. Or? >> >> Thanks. Yes, It will more helpful if we can handle this in the i2c core. > > To understand the issue better: which kind of devices in your system > still send

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On 2 May 2018 at 13:23, Wolfram Sang wrote: > >> > We should maybe handle this in the core somewhen, though. Or? >> >> Thanks. Yes, It will more helpful if we can handle this in the i2c core. > > To understand the issue better: which kind of devices in your system > still send I2C transfers when

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

> > We should maybe handle this in the core somewhen, though. Or? > > Thanks. Yes, It will more helpful if we can handle this in the i2c core. To understand the issue better: which kind of devices in your system still send I2C transfers when the system is going to suspend? Do you know?

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

> > We should maybe handle this in the core somewhen, though. Or? > > Thanks. Yes, It will more helpful if we can handle this in the i2c core. To understand the issue better: which kind of devices in your system still send I2C transfers when the system is going to suspend? Do you know?

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

Hi Wolfram, On 27 April 2018 at 20:14, Wolfram Sang wrote: > On Mon, Apr 09, 2018 at 02:40:54PM +0800, Baolin Wang wrote: >> Add one flag to indicate if the i2c controller has been in suspend state, >> which can prevent i2c accesses after i2c controller is suspended following

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

Hi Wolfram, On 27 April 2018 at 20:14, Wolfram Sang wrote: > On Mon, Apr 09, 2018 at 02:40:54PM +0800, Baolin Wang wrote: >> Add one flag to indicate if the i2c controller has been in suspend state, >> which can prevent i2c accesses after i2c controller is suspended following >> system suspend.

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On Mon, Apr 09, 2018 at 02:40:54PM +0800, Baolin Wang wrote: > Add one flag to indicate if the i2c controller has been in suspend state, > which can prevent i2c accesses after i2c controller is suspended following > system suspend. > > Signed-off-by: Baolin Wang Applied

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On Mon, Apr 09, 2018 at 02:40:54PM +0800, Baolin Wang wrote: > Add one flag to indicate if the i2c controller has been in suspend state, > which can prevent i2c accesses after i2c controller is suspended following > system suspend. > > Signed-off-by: Baolin Wang Applied to for-current, thanks!

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

Hi Grygorii, On 10 April 2018 at 04:56, Grygorii Strashko wrote: > > > On 04/09/2018 01:40 AM, Baolin Wang wrote: >> Add one flag to indicate if the i2c controller has been in suspend state, >> which can prevent i2c accesses after i2c controller is suspended following

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

Hi Grygorii, On 10 April 2018 at 04:56, Grygorii Strashko wrote: > > > On 04/09/2018 01:40 AM, Baolin Wang wrote: >> Add one flag to indicate if the i2c controller has been in suspend state, >> which can prevent i2c accesses after i2c controller is suspended following >> system suspend. > > This

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On 04/09/2018 01:40 AM, Baolin Wang wrote: > Add one flag to indicate if the i2c controller has been in suspend state, > which can prevent i2c accesses after i2c controller is suspended following > system suspend. This usually indicates some bigger problem - there should be no i2c access to

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On 04/09/2018 01:40 AM, Baolin Wang wrote: > Add one flag to indicate if the i2c controller has been in suspend state, > which can prevent i2c accesses after i2c controller is suspended following > system suspend. This usually indicates some bigger problem - there should be no i2c access to

[PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

Add one flag to indicate if the i2c controller has been in suspend state, which can prevent i2c accesses after i2c controller is suspended following system suspend. Signed-off-by: Baolin Wang --- drivers/i2c/busses/i2c-sprd.c | 16 1 file changed, 16

[PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

Add one flag to indicate if the i2c controller has been in suspend state, which can prevent i2c accesses after i2c controller is suspended following system suspend. Signed-off-by: Baolin Wang --- drivers/i2c/busses/i2c-sprd.c | 16 1 file changed, 16 insertions(+) diff --git