Re: CM32181 Bug Report (Linux 6.0+)

[Jonathan Cameron <jic23@kernel.org>]

On Sat, 07 Jan 2023 00:37:40 +0000
Wahaj <wahajaved@protonmail.com> wrote:

> ------- Original Message -------
> On Friday, January 6th, 2023 at 9:08 AM, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> 
> 
> > Hi Wahaj,
> > 
> > On Fri, Jan 6, 2023 at 12:26 AM Wahaj wahajaved@protonmail.com wrote:
> >   
> > > ------- Original Message -------
> > > 
> > > On Tuesday, January 3rd, 2023 at 2:26 PM, Jonathan Cameron Jonathan.Cameron@Huawei.com wrote:
> > >   
> > > > On Wed, 28 Dec 2022 14:05:24 +0000
> > > > Wahaj wahajaved@protonmail.com wrote:  
> > >   
> > > > > Hi Jonathan
> > > > > 
> > > > > Hope you're doing well. I have been using a laptop that comes with a
> > > > > CM32181 Light Sensor and after upgrading to the Linux kernel 6.0+, my
> > > > > laptop cannot seem to suspend because of the PM subsystem error. I
> > > > > have narrowed the problem down to this module and I believe that the
> > > > > commit 68c1b3dd5c48b2323067f8c1f0649ae2f31ab20bis the culprit
> > > > > 
> > > > > The following lines were provided from the journalctl logs:
> > > > >   
> > > > > > cm32181 i2c-CPLM3218:00: PM: dpm_run_callback():
> > > > > > acpi_subsys_suspend+0x0/0x60 returns -121 cm32181 i2c-CPLM3218:00:
> > > > > > PM: failed to suspend async: error -121  
> > > > > 
> > > > > I would love the chance to be able to work on this given any guidance
> > > > > on where to start  
> > > > 
> > > > Hi Wahaj,
> > > > 
> > > > Certainly seems likely that you have identified the right commit.
> > > > As a starting point, resend this email to linux-iio@vger.kernel.org
> > > > and Kai-Heng Feng kai.heng.feng@canonical.com
> > > > 
> > > > If you could try reverting the commit to be completely sure it is
> > > > the cause that would help avoid any doubt.
> > > > Superficially the only thing that I can see causing this problem is
> > > > a fail of the i2c bus write.
> > > > 
> > > > Does the device work prior to suspend? Try cat /sys/bus/iio/iio:device0/*
> > > > and see if you get any errors (may be device1 etc)
> > > > 
> > > > If the device wasn't working at all the register writes in probe() should
> > > > have failed so we shouldn't be trying to suspend it.
> > > > It's possible your machine has some unusual power dependencies or
> > > > similar that mean the device is getting powered down before we try to
> > > > suspend it.
> > > > 
> > > > Anyhow, better to have this discussion on list as there are many other people
> > > > who may have more insight than me or be able to replicate and help debug.
> > > > 
> > > > Jonathan
> > > >   
> > > > > Best Regards,
> > > > > Wahaj Javed  
> > > 
> > > Hi Jonathan and Kai-Heng Feng,
> > > 
> > > I am currently using the 5.15 linux kernel for a while now which works perfectly fine.
> > > 
> > > From what I gather the suspend functionality does work when using an older Linux version without the PM i2c bus writes.  
> > 
> > 
> > Does your system use S3 or S2idle to perform suspend?
> >   
> My system uses S3 to perform suspend
> > > The device does work fine prior to and post attempted suspend with no errors showing in cat /sys/bus/iio/iio:device0/*  
> > 
> > 
> > Does in_illuminance_input value change after system suspend?  
> Yes, the in_illuminance_input value changes after system suspend with or without the suspend and resume functions
> 
> 
> > 
> > Kai-Heng
> >   
> > > Let me know if there's anything I should start looking into
> > > 
> > > Best Regards
> > > Wahaj Javed  
> 
> How did the kernel used to suspend/resume before using the suspend and resume functions in the light sensor?
> 
> Was the DEFINE_SIMPLE_DEV_PM_OPS introduced as a part of the Linux 6.0+ PM rework?

Until https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68c1b3dd5c48b2323067f8c1f0649ae2f31ab20b
which will have hit mainline in 6.0, the driver had no suspend / resume support.

That patch introduced an i2c write to put the chip into a low power mode.
My best guess for a cause would be that something else is incorrectly being disabled
before this call and hence breaking the i2c comms.

Jonathan

> 
> I would like to take on this bug and try to solve it if that's possible
> 
> 
> Best Regards
> Wahaj Javed