------- Original Message ------- On Friday, January 6th, 2023 at 9:08 AM, Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx> wrote: > Hi Wahaj, > > On Fri, Jan 6, 2023 at 12:26 AM Wahaj wahajaved@xxxxxxxxxxxxxx wrote: > > > ------- Original Message ------- > > > > On Tuesday, January 3rd, 2023 at 2:26 PM, Jonathan Cameron Jonathan.Cameron@xxxxxxxxxx wrote: > > > > > On Wed, 28 Dec 2022 14:05:24 +0000 > > > Wahaj wahajaved@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx > > > and Kai-Heng Feng kai.heng.feng@xxxxxxxxxxxxx > > > > > > 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? I would like to take on this bug and try to solve it if that's possible Best Regards Wahaj Javed
