All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
       [not found] ` <7hv9y01z85.fsf@baylibre.com>
@ 2019-05-24  1:29   ` Stephen Boyd
  2019-05-26 21:51     ` Amit Kucheria
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Boyd @ 2019-05-24  1:29 UTC (permalink / raw)
  To: kernelci.org bot, Kevin Hilman, kernel-build-reports,
	Amit Kucheria, linux-arm-msm
  Cc: andygro

Quoting Kevin Hilman (2019-05-23 17:18:50)
> [ + Andy Gross, Stephen Boyd ]
> 
> "kernelci.org bot" <bot@kernelci.org> writes:
> 
> > next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
> >
> > Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/pending-fixes/kernel/v5.2-rc1-375-g3695b18d1e9cd/
> > Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g3695b18d1e9cd/
> >
> > Tree: next
> > Branch: pending-fixes
> > Git Describe: v5.2-rc1-375-g3695b18d1e9cd
> > Git Commit: 3695b18d1e9cd6bb739579e782670518d500839d
> > Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > Tested: 82 unique boards, 24 SoC families, 19 builds out of 223
> >
> > Boot Regressions Detected:
> >
> > arm:
> >
> >     qcom_defconfig:
> >         gcc-8:
> >           qcom-apq8064-cm-qs600:
> >               lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
> >           qcom-apq8064-ifc6410:
> >               lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
> 
> Andy, 8064 not happy in linux-next lately, I haven't had a chance to
> look closer.
> 

Looks like some sort of tsens crash with a bad regmap_field or something.

[    4.001041] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    4.008631] pgd = (ptrval)
[    4.016914] [00000000] *pgd=00000000
[    4.019374] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[    4.023100] Modules linked in:
[    4.028402] CPU: 2 PID: 21 Comm: kworker/2:0 Tainted: G        W         5.2.0-rc1 #1
[    4.031259] Hardware name: Generic DT based system
[    4.039175] Workqueue: events deferred_probe_work_func
[    4.043859] PC is at regmap_field_read+0x1c/0x70
[    4.048973] LR is at is_sensor_enabled+0x40/0x74
[    4.053743] pc : []    lr : []    psr: 20000013
[    4.058340] sp : c02f1dc8  ip : 00000000  fp : 00000007
[    4.064332] r10: c0de1534  r9 : c0bb596c  r8 : ee4eda00
[    4.068214] usb 1-1: New USB device found, idVendor=04b4, idProduct=6570, bcdDevice=32.99
[    4.069539] r7 : c02f0000  r6 : c02f1de0  r5 : 00000000  r4 : c02f0000
[    4.069549] r3 : c02f1dc8  r2 : 11403009  r1 : c02f1de0  r0 : 00000000
[    4.074838] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    4.083085] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    4.083096] Control: 10c5787d  Table: 8020406a  DAC: 00000051
[    4.083108] Process kworker/2:0 (pid: 21, stack limit = 0x(ptrval))
[    4.083118] Stack: (0xc02f1dc8 to 0xc02f2000)
[    4.083152] 1dc0:                   c02f0000 c093d93c c02f0000 00000000 00000000 c093dabc
[    4.083192] 1de0: 0000000b 11403009 ee39b040 ee39b040 ee39b040 c093d794 00000000 11403009
[    4.089507] usb 1-1: Product: USB2.0 Hub
[    4.096045] 1e00: 0000000b 11403009 ee4eda10 00000000 c10a2b84 00000000 c10c2f78 00000000
[    4.096085] 1e20: c10a2b84 c080b940 c110b37c ee4eda10 c110b380 00000000 c10c2f78 c0809480
[    4.096126] 1e40: c02f1ecc ee4eda10 ffffe000 ee4eda10 c10a2b84 c02f1ecc c0809b78 00000001
[    4.105168] hub 1-1:1.0: USB hub found
[    4.110367] 1e60: c0dbb994 c10c2f78 ffffe000 c0809938 ee4eda10 00000001 00000001 00000000
[    4.116581] hub 1-1:1.0: 4 ports detected
[    4.122170] 1e80: c02f0000 c02f1ecc c0809b78 00000001 c0dbb994 c10c2f78 ffffe000 c0807718
[    4.187285] 1ea0: ffffe000 c028c26c ee20acb8 11403009 ee4eda10 ee4eda10 c02f0000 ee4eda54
[    4.195443] 1ec0: c10938a8 c08092d8 ee4eda10 ee4eda10 00000001 11403009 ee4eda10 ee4eda10
[    4.203603] 1ee0: c1093b18 c10938a8 c10c2f78 c08084e4 ee4eda10 c1093894 c1093894 c0808a2c
[    4.211762] 1f00: c10938cc c0208880 eefc0cc0 eefc3e00 00000000 c10b76b0 00000000 c033c804
[    4.219921] 1f20: eefc0cc0 eefc0cc0 eefc0cd8 c0208880 c0208894 eefc0cc0 00000108 c1003d00
[    4.228082] 1f40: eefc0cd8 eefc0cc0 ffffe000 c033d6dc c023ed00 c10b70e8 c0d44c58 00000000
[    4.236242] 1f60: c023ed1c c023ed00 c023ec80 00000000 c02f0000 c0208880 c033d448 c029bdec
[    4.244400] 1f80: c023ed1c c034289c 00000000 c023ec80 c0342754 00000000 00000000 00000000
[    4.252559] 1fa0: 00000000 00000000 00000000 c03010e8 00000000 00000000 00000000 00000000
[    4.260719] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.268878] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    4.277031] [] (regmap_field_read) from [] (is_sensor_enabled+0x40/0x74)
[    4.285185] [] (is_sensor_enabled) from [] (tsens_probe+0x170/0x2d4)
[    4.293699] [] (tsens_probe) from [] (platform_drv_probe+0x48/0x98)
[    4.301764] [] (platform_drv_probe) from [] (really_probe+0x108/0x40c)
[    4.309490] [] (really_probe) from [] (driver_probe_device+0x78/0x1c0)
[    4.317822] [] (driver_probe_device) from [] (bus_for_each_drv+0x84/0xc8)
[    4.326069] [] (bus_for_each_drv) from [] (__device_attach+0xd4/0x16c)
[    4.334662] [] (__device_attach) from [] (bus_probe_device+0x84/0x8c)
[    4.342815] [] (bus_probe_device) from [] (deferred_probe_work_func+0x84/0xc4)
[    4.351081] [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x570)
[    4.359935] [] (process_one_work) from [] (worker_thread+0x294/0x580)
[    4.369218] [] (worker_thread) from [] (kthread+0x148/0x150)
[    4.377288] [] (kthread) from [] (ret_from_fork+0x14/0x2c)
[    4.384735] Exception stack(0xc02f1fb0 to 0xc02f1ff8)
[    4.391775] 1fa0:                                     00000000 00000000 00000000 00000000
[    4.396916] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.405068] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    4.413232] Code: e1a06001 e1a0300d e3c34d7f e3c4403f 

[1] https://storage.kernelci.org/next/pending-fixes/v5.2-rc1-375-g3695b18d1e9cd/arm/qcom_defconfig/gcc-8/lab-baylibre-seattle/boot-qcom-apq8064-cm-qs600.html

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
  2019-05-24  1:29   ` next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd) Stephen Boyd
@ 2019-05-26 21:51     ` Amit Kucheria
  2019-05-28 18:09       ` Andy Gross
  2019-05-28 20:17       ` next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd) Kevin Hilman
  0 siblings, 2 replies; 7+ messages in thread
From: Amit Kucheria @ 2019-05-26 21:51 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: kernelci.org bot, Kevin Hilman, kernel-build-reports,
	linux-arm-msm, andygro, Bjorn Andersson

On Fri, May 24, 2019 at 3:29 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Kevin Hilman (2019-05-23 17:18:50)
> > [ + Andy Gross, Stephen Boyd ]
> >
> > "kernelci.org bot" <bot@kernelci.org> writes:
> >
> > > next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
> > >
> > > Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/pending-fixes/kernel/v5.2-rc1-375-g3695b18d1e9cd/
> > > Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g3695b18d1e9cd/
> > >
> > > Tree: next
> > > Branch: pending-fixes
> > > Git Describe: v5.2-rc1-375-g3695b18d1e9cd
> > > Git Commit: 3695b18d1e9cd6bb739579e782670518d500839d
> > > Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > > Tested: 82 unique boards, 24 SoC families, 19 builds out of 223
> > >
> > > Boot Regressions Detected:
> > >
> > > arm:
> > >
> > >     qcom_defconfig:
> > >         gcc-8:
> > >           qcom-apq8064-cm-qs600:
> > >               lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
> > >           qcom-apq8064-ifc6410:
> > >               lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
> >
> > Andy, 8064 not happy in linux-next lately, I haven't had a chance to
> > look closer.
> >
>
> Looks like some sort of tsens crash with a bad regmap_field or something.
>
> [    4.001041] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [    4.008631] pgd = (ptrval)
> [    4.016914] [00000000] *pgd=00000000
> [    4.019374] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> [    4.023100] Modules linked in:
> [    4.028402] CPU: 2 PID: 21 Comm: kworker/2:0 Tainted: G        W         5.2.0-rc1 #1
> [    4.031259] Hardware name: Generic DT based system
> [    4.039175] Workqueue: events deferred_probe_work_func
> [    4.043859] PC is at regmap_field_read+0x1c/0x70
> [    4.048973] LR is at is_sensor_enabled+0x40/0x74
> [    4.053743] pc : []    lr : []    psr: 20000013
> [    4.058340] sp : c02f1dc8  ip : 00000000  fp : 00000007
> [    4.064332] r10: c0de1534  r9 : c0bb596c  r8 : ee4eda00
> [    4.068214] usb 1-1: New USB device found, idVendor=04b4, idProduct=6570, bcdDevice=32.99
> [    4.069539] r7 : c02f0000  r6 : c02f1de0  r5 : 00000000  r4 : c02f0000
> [    4.069549] r3 : c02f1dc8  r2 : 11403009  r1 : c02f1de0  r0 : 00000000
> [    4.074838] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
> [    4.083085] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [    4.083096] Control: 10c5787d  Table: 8020406a  DAC: 00000051
> [    4.083108] Process kworker/2:0 (pid: 21, stack limit = 0x(ptrval))
> [    4.083118] Stack: (0xc02f1dc8 to 0xc02f2000)
> [    4.083152] 1dc0:                   c02f0000 c093d93c c02f0000 00000000 00000000 c093dabc
> [    4.083192] 1de0: 0000000b 11403009 ee39b040 ee39b040 ee39b040 c093d794 00000000 11403009
> [    4.089507] usb 1-1: Product: USB2.0 Hub
> [    4.096045] 1e00: 0000000b 11403009 ee4eda10 00000000 c10a2b84 00000000 c10c2f78 00000000
> [    4.096085] 1e20: c10a2b84 c080b940 c110b37c ee4eda10 c110b380 00000000 c10c2f78 c0809480
> [    4.096126] 1e40: c02f1ecc ee4eda10 ffffe000 ee4eda10 c10a2b84 c02f1ecc c0809b78 00000001
> [    4.105168] hub 1-1:1.0: USB hub found
> [    4.110367] 1e60: c0dbb994 c10c2f78 ffffe000 c0809938 ee4eda10 00000001 00000001 00000000
> [    4.116581] hub 1-1:1.0: 4 ports detected
> [    4.122170] 1e80: c02f0000 c02f1ecc c0809b78 00000001 c0dbb994 c10c2f78 ffffe000 c0807718
> [    4.187285] 1ea0: ffffe000 c028c26c ee20acb8 11403009 ee4eda10 ee4eda10 c02f0000 ee4eda54
> [    4.195443] 1ec0: c10938a8 c08092d8 ee4eda10 ee4eda10 00000001 11403009 ee4eda10 ee4eda10
> [    4.203603] 1ee0: c1093b18 c10938a8 c10c2f78 c08084e4 ee4eda10 c1093894 c1093894 c0808a2c
> [    4.211762] 1f00: c10938cc c0208880 eefc0cc0 eefc3e00 00000000 c10b76b0 00000000 c033c804
> [    4.219921] 1f20: eefc0cc0 eefc0cc0 eefc0cd8 c0208880 c0208894 eefc0cc0 00000108 c1003d00
> [    4.228082] 1f40: eefc0cd8 eefc0cc0 ffffe000 c033d6dc c023ed00 c10b70e8 c0d44c58 00000000
> [    4.236242] 1f60: c023ed1c c023ed00 c023ec80 00000000 c02f0000 c0208880 c033d448 c029bdec
> [    4.244400] 1f80: c023ed1c c034289c 00000000 c023ec80 c0342754 00000000 00000000 00000000
> [    4.252559] 1fa0: 00000000 00000000 00000000 c03010e8 00000000 00000000 00000000 00000000
> [    4.260719] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    4.268878] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [    4.277031] [] (regmap_field_read) from [] (is_sensor_enabled+0x40/0x74)

Sorry for breaking the boot on 8064. That was one of the platforms
that I didn't convert over to regmap (needs more refactoring). I had
hoped kernelci would catch any issues but looks like thermal-soc tree
entered linux-next quite late and didn't catch this.

Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new
operation to check if a sensor is enabled") fix the issue? If so,
reverting that commit might be the best course of action since I've
started vacations and can't fix this for 8064 in a meaningful amount
of time (until 3rd week of June). cc'ing Bjorn in case this needs more
investigation, but I think that patch is fairly self contained and
reverting it shouldn't have any knock-on effects.

Regards,
Amit

> [    4.285185] [] (is_sensor_enabled) from [] (tsens_probe+0x170/0x2d4)
> [    4.293699] [] (tsens_probe) from [] (platform_drv_probe+0x48/0x98)
> [    4.301764] [] (platform_drv_probe) from [] (really_probe+0x108/0x40c)
> [    4.309490] [] (really_probe) from [] (driver_probe_device+0x78/0x1c0)
> [    4.317822] [] (driver_probe_device) from [] (bus_for_each_drv+0x84/0xc8)
> [    4.326069] [] (bus_for_each_drv) from [] (__device_attach+0xd4/0x16c)
> [    4.334662] [] (__device_attach) from [] (bus_probe_device+0x84/0x8c)
> [    4.342815] [] (bus_probe_device) from [] (deferred_probe_work_func+0x84/0xc4)
> [    4.351081] [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x570)
> [    4.359935] [] (process_one_work) from [] (worker_thread+0x294/0x580)
> [    4.369218] [] (worker_thread) from [] (kthread+0x148/0x150)
> [    4.377288] [] (kthread) from [] (ret_from_fork+0x14/0x2c)
> [    4.384735] Exception stack(0xc02f1fb0 to 0xc02f1ff8)
> [    4.391775] 1fa0:                                     00000000 00000000 00000000 00000000
> [    4.396916] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    4.405068] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [    4.413232] Code: e1a06001 e1a0300d e3c34d7f e3c4403f
>
> [1] https://storage.kernelci.org/next/pending-fixes/v5.2-rc1-375-g3695b18d1e9cd/arm/qcom_defconfig/gcc-8/lab-baylibre-seattle/boot-qcom-apq8064-cm-qs600.html

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
  2019-05-26 21:51     ` Amit Kucheria
@ 2019-05-28 18:09       ` Andy Gross
       [not found]         ` <CAJ=6tTr4EaLLiavN+aRpU3JnJ5MuAtU-uer_8iLm7QMh6i4rAg@mail.gmail.com>
  2019-05-28 20:17       ` next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd) Kevin Hilman
  1 sibling, 1 reply; 7+ messages in thread
From: Andy Gross @ 2019-05-28 18:09 UTC (permalink / raw)
  To: Amit Kucheria
  Cc: Stephen Boyd, kernelci.org bot, Kevin Hilman,
	kernel-build-reports, linux-arm-msm, Bjorn Andersson

On Sun, May 26, 2019 at 4:51 PM Amit Kucheria <amit.kucheria@linaro.org> wrote:

<snip>

> Sorry for breaking the boot on 8064. That was one of the platforms
> that I didn't convert over to regmap (needs more refactoring). I had
> hoped kernelci would catch any issues but looks like thermal-soc tree
> entered linux-next quite late and didn't catch this.
>
> Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new
> operation to check if a sensor is enabled") fix the issue? If so,
> reverting that commit might be the best course of action since I've
> started vacations and can't fix this for 8064 in a meaningful amount
> of time (until 3rd week of June). cc'ing Bjorn in case this needs more
> investigation, but I think that patch is fairly self contained and
> reverting it shouldn't have any knock-on effects.

I am ok with this.  I'll check with Bjorn before adding this to a
fixes for -rc2.

Andy

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
  2019-05-26 21:51     ` Amit Kucheria
  2019-05-28 18:09       ` Andy Gross
@ 2019-05-28 20:17       ` Kevin Hilman
  1 sibling, 0 replies; 7+ messages in thread
From: Kevin Hilman @ 2019-05-28 20:17 UTC (permalink / raw)
  To: Amit Kucheria, Stephen Boyd
  Cc: kernelci.org bot, kernel-build-reports, linux-arm-msm, andygro,
	Bjorn Andersson

Amit Kucheria <amit.kucheria@linaro.org> writes:

> On Fri, May 24, 2019 at 3:29 AM Stephen Boyd <sboyd@kernel.org> wrote:
>>
>> Quoting Kevin Hilman (2019-05-23 17:18:50)
>> > [ + Andy Gross, Stephen Boyd ]
>> >
>> > "kernelci.org bot" <bot@kernelci.org> writes:
>> >
>> > > next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
>> > >
>> > > Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/pending-fixes/kernel/v5.2-rc1-375-g3695b18d1e9cd/
>> > > Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g3695b18d1e9cd/
>> > >
>> > > Tree: next
>> > > Branch: pending-fixes
>> > > Git Describe: v5.2-rc1-375-g3695b18d1e9cd
>> > > Git Commit: 3695b18d1e9cd6bb739579e782670518d500839d
>> > > Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> > > Tested: 82 unique boards, 24 SoC families, 19 builds out of 223
>> > >
>> > > Boot Regressions Detected:
>> > >
>> > > arm:
>> > >
>> > >     qcom_defconfig:
>> > >         gcc-8:
>> > >           qcom-apq8064-cm-qs600:
>> > >               lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
>> > >           qcom-apq8064-ifc6410:
>> > >               lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
>> >
>> > Andy, 8064 not happy in linux-next lately, I haven't had a chance to
>> > look closer.
>> >
>>
>> Looks like some sort of tsens crash with a bad regmap_field or something.
>>
>> [    4.001041] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> [    4.008631] pgd = (ptrval)
>> [    4.016914] [00000000] *pgd=00000000
>> [    4.019374] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>> [    4.023100] Modules linked in:
>> [    4.028402] CPU: 2 PID: 21 Comm: kworker/2:0 Tainted: G        W         5.2.0-rc1 #1
>> [    4.031259] Hardware name: Generic DT based system
>> [    4.039175] Workqueue: events deferred_probe_work_func
>> [    4.043859] PC is at regmap_field_read+0x1c/0x70
>> [    4.048973] LR is at is_sensor_enabled+0x40/0x74
>> [    4.053743] pc : []    lr : []    psr: 20000013
>> [    4.058340] sp : c02f1dc8  ip : 00000000  fp : 00000007
>> [    4.064332] r10: c0de1534  r9 : c0bb596c  r8 : ee4eda00
>> [    4.068214] usb 1-1: New USB device found, idVendor=04b4, idProduct=6570, bcdDevice=32.99
>> [    4.069539] r7 : c02f0000  r6 : c02f1de0  r5 : 00000000  r4 : c02f0000
>> [    4.069549] r3 : c02f1dc8  r2 : 11403009  r1 : c02f1de0  r0 : 00000000
>> [    4.074838] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
>> [    4.083085] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
>> [    4.083096] Control: 10c5787d  Table: 8020406a  DAC: 00000051
>> [    4.083108] Process kworker/2:0 (pid: 21, stack limit = 0x(ptrval))
>> [    4.083118] Stack: (0xc02f1dc8 to 0xc02f2000)
>> [    4.083152] 1dc0:                   c02f0000 c093d93c c02f0000 00000000 00000000 c093dabc
>> [    4.083192] 1de0: 0000000b 11403009 ee39b040 ee39b040 ee39b040 c093d794 00000000 11403009
>> [    4.089507] usb 1-1: Product: USB2.0 Hub
>> [    4.096045] 1e00: 0000000b 11403009 ee4eda10 00000000 c10a2b84 00000000 c10c2f78 00000000
>> [    4.096085] 1e20: c10a2b84 c080b940 c110b37c ee4eda10 c110b380 00000000 c10c2f78 c0809480
>> [    4.096126] 1e40: c02f1ecc ee4eda10 ffffe000 ee4eda10 c10a2b84 c02f1ecc c0809b78 00000001
>> [    4.105168] hub 1-1:1.0: USB hub found
>> [    4.110367] 1e60: c0dbb994 c10c2f78 ffffe000 c0809938 ee4eda10 00000001 00000001 00000000
>> [    4.116581] hub 1-1:1.0: 4 ports detected
>> [    4.122170] 1e80: c02f0000 c02f1ecc c0809b78 00000001 c0dbb994 c10c2f78 ffffe000 c0807718
>> [    4.187285] 1ea0: ffffe000 c028c26c ee20acb8 11403009 ee4eda10 ee4eda10 c02f0000 ee4eda54
>> [    4.195443] 1ec0: c10938a8 c08092d8 ee4eda10 ee4eda10 00000001 11403009 ee4eda10 ee4eda10
>> [    4.203603] 1ee0: c1093b18 c10938a8 c10c2f78 c08084e4 ee4eda10 c1093894 c1093894 c0808a2c
>> [    4.211762] 1f00: c10938cc c0208880 eefc0cc0 eefc3e00 00000000 c10b76b0 00000000 c033c804
>> [    4.219921] 1f20: eefc0cc0 eefc0cc0 eefc0cd8 c0208880 c0208894 eefc0cc0 00000108 c1003d00
>> [    4.228082] 1f40: eefc0cd8 eefc0cc0 ffffe000 c033d6dc c023ed00 c10b70e8 c0d44c58 00000000
>> [    4.236242] 1f60: c023ed1c c023ed00 c023ec80 00000000 c02f0000 c0208880 c033d448 c029bdec
>> [    4.244400] 1f80: c023ed1c c034289c 00000000 c023ec80 c0342754 00000000 00000000 00000000
>> [    4.252559] 1fa0: 00000000 00000000 00000000 c03010e8 00000000 00000000 00000000 00000000
>> [    4.260719] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> [    4.268878] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
>> [    4.277031] [] (regmap_field_read) from [] (is_sensor_enabled+0x40/0x74)
>
> Sorry for breaking the boot on 8064. That was one of the platforms
> that I didn't convert over to regmap (needs more refactoring). I had
> hoped kernelci would catch any issues but looks like thermal-soc tree
> entered linux-next quite late and didn't catch this.
>
> Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new
> operation to check if a sensor is enabled") fix the issue? If so,
> reverting that commit might be the best course of action since I've
> started vacations and can't fix this for 8064 in a meaningful amount
> of time (until 3rd week of June). cc'ing Bjorn in case this needs more
> investigation, but I think that patch is fairly self contained and
> reverting it shouldn't have any knock-on effects.

Tested-by: Kevin Hilman <khilman@baylibre.com>

Reverting that commit gets things booting again in my lab.

Kevin

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
       [not found]         ` <CAJ=6tTr4EaLLiavN+aRpU3JnJ5MuAtU-uer_8iLm7QMh6i4rAg@mail.gmail.com>
@ 2019-05-29  1:06           ` Eduardo Valentin
  2019-05-29  1:19             ` Andy Gross
  0 siblings, 1 reply; 7+ messages in thread
From: Eduardo Valentin @ 2019-05-29  1:06 UTC (permalink / raw)
  To: Andy Gross
  Cc: Amit Kucheria, Stephen Boyd, kernelci.org bot, Kevin Hilman,
	kernel-build-reports, linux-arm-msm, Bjorn Andersson

Hello,

On Tue, May 28, 2019 at 04:37:15PM -0500, Andy Gross wrote:
> +Eduardo
> 
> On Tue, May 28, 2019 at 1:09 PM Andy Gross <andygro@gmail.com> wrote:
> 
> > On Sun, May 26, 2019 at 4:51 PM Amit Kucheria <amit.kucheria@linaro.org>
> > wrote:
> >
> > <snip>
> >
> > > Sorry for breaking the boot on 8064. That was one of the platforms
> > > that I didn't convert over to regmap (needs more refactoring). I had
> > > hoped kernelci would catch any issues but looks like thermal-soc tree
> > > entered linux-next quite late and didn't catch this.
> > >
> > > Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new
> > > operation to check if a sensor is enabled") fix the issue? If so,
> > > reverting that commit might be the best course of action since I've
> > > started vacations and can't fix this for 8064 in a meaningful amount
> > > of time (until 3rd week of June). cc'ing Bjorn in case this needs more
> > > investigation, but I think that patch is fairly self contained and
> > > reverting it shouldn't have any knock-on effects.
> >
> > I am ok with this.  I'll check with Bjorn before adding this to a
> > fixes for -rc2.
> >
> 
> Eduardo, we have a situation with the Qcom tsens driver and
> commit  3e6a8fb33084.  Do you mind if I send in a revert for this through
> my tree or can you do this for us for -rc2?

I can revert this patch. I can confirm that it is selfcontained and
reverting seams to work. I am sending the revert to -rc3, as rc2 is
already out.

> 
> Thanks,
> Andy

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
  2019-05-29  1:06           ` Eduardo Valentin
@ 2019-05-29  1:19             ` Andy Gross
  2019-05-29  2:34               ` [PATCH 1/1] Revert "drivers: thermal: tsens: Add new operation to check if a sensor is enabled" Eduardo Valentin
  0 siblings, 1 reply; 7+ messages in thread
From: Andy Gross @ 2019-05-29  1:19 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: Amit Kucheria, Stephen Boyd, kernelci.org bot, Kevin Hilman,
	kernel-build-reports, linux-arm-msm, Bjorn Andersson

On Tue, May 28, 2019 at 8:06 PM Eduardo Valentin <edubezval@gmail.com> wrote:
>
> Hello,
>
> On Tue, May 28, 2019 at 04:37:15PM -0500, Andy Gross wrote:
> > +Eduardo
> >
> > On Tue, May 28, 2019 at 1:09 PM Andy Gross <andygro@gmail.com> wrote:
> >
> > > On Sun, May 26, 2019 at 4:51 PM Amit Kucheria <amit.kucheria@linaro.org>
> > > wrote:
> > >
> > > <snip>
> > >
> > > > Sorry for breaking the boot on 8064. That was one of the platforms
> > > > that I didn't convert over to regmap (needs more refactoring). I had
> > > > hoped kernelci would catch any issues but looks like thermal-soc tree
> > > > entered linux-next quite late and didn't catch this.
> > > >
> > > > Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new
> > > > operation to check if a sensor is enabled") fix the issue? If so,
> > > > reverting that commit might be the best course of action since I've
> > > > started vacations and can't fix this for 8064 in a meaningful amount
> > > > of time (until 3rd week of June). cc'ing Bjorn in case this needs more
> > > > investigation, but I think that patch is fairly self contained and
> > > > reverting it shouldn't have any knock-on effects.
> > >
> > > I am ok with this.  I'll check with Bjorn before adding this to a
> > > fixes for -rc2.
> > >
> >
> > Eduardo, we have a situation with the Qcom tsens driver and
> > commit  3e6a8fb33084.  Do you mind if I send in a revert for this through
> > my tree or can you do this for us for -rc2?
>
> I can revert this patch. I can confirm that it is selfcontained and
> reverting seams to work. I am sending the revert to -rc3, as rc2 is
> already out.

Perfect.  Thanks Eduardo!

Andy

^ permalink raw reply	[flat|nested] 7+ messages in thread
* [PATCH 1/1] Revert "drivers: thermal: tsens: Add new operation to check if a sensor is enabled"
  2019-05-29  1:19             ` Andy Gross
@ 2019-05-29  2:34               ` Eduardo Valentin
  0 siblings, 0 replies; 7+ messages in thread
From: Eduardo Valentin @ 2019-05-29  2:34 UTC (permalink / raw)
  To: linux-arm-msm, linux-pm, linux-kernel
  Cc: Stephen Boyd, bot, Kevin Hilman, kernel-build-reports,
	Bjorn Andersson, Eduardo Valentin, Andy Gross, David Brown,
	Amit Kucheria, Zhang Rui, Daniel Lezcano

This reverts commit 3e6a8fb3308419129c7a52de6eb42feef5a919a0.

Cc: Andy Gross <agross@kernel.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Amit Kucheria <amit.kucheria@linaro.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Suggested-by: Amit Kucheria <amit.kucheria@linaro.org>
Reported-by: Andy Gross <andygro@gmail.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
---

Added this for next -rc, as per request.

 drivers/thermal/qcom/tsens-common.c | 14 --------------
 drivers/thermal/qcom/tsens-v0_1.c   |  1 -
 drivers/thermal/qcom/tsens-v2.c     |  1 -
 drivers/thermal/qcom/tsens.c        |  5 -----
 drivers/thermal/qcom/tsens.h        |  1 -
 5 files changed, 22 deletions(-)

diff --git a/drivers/thermal/qcom/tsens-common.c b/drivers/thermal/qcom/tsens-common.c
index 928e8e8..528df88 100644
--- a/drivers/thermal/qcom/tsens-common.c
+++ b/drivers/thermal/qcom/tsens-common.c
@@ -64,20 +64,6 @@ void compute_intercept_slope(struct tsens_priv *priv, u32 *p1,
 	}
 }
 
-bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id)
-{
-	u32 val;
-	int ret;
-
-	if ((hw_id > (priv->num_sensors - 1)) || (hw_id < 0))
-		return -EINVAL;
-	ret = regmap_field_read(priv->rf[SENSOR_EN], &val);
-	if (ret)
-		return ret;
-
-	return val & (1 << hw_id);
-}
-
 static inline int code_to_degc(u32 adc_code, const struct tsens_sensor *s)
 {
 	int degc, num, den;
diff --git a/drivers/thermal/qcom/tsens-v0_1.c b/drivers/thermal/qcom/tsens-v0_1.c
index a319283..6f26fad 100644
--- a/drivers/thermal/qcom/tsens-v0_1.c
+++ b/drivers/thermal/qcom/tsens-v0_1.c
@@ -334,7 +334,6 @@ static const struct reg_field tsens_v0_1_regfields[MAX_REGFIELDS] = {
 	/* CTRL_OFFSET */
 	[TSENS_EN]     = REG_FIELD(SROT_CTRL_OFF, 0,  0),
 	[TSENS_SW_RST] = REG_FIELD(SROT_CTRL_OFF, 1,  1),
-	[SENSOR_EN]    = REG_FIELD(SROT_CTRL_OFF, 3, 13),
 
 	/* ----- TM ------ */
 	/* INTERRUPT ENABLE */
diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
index 1099069..0a4f2b8 100644
--- a/drivers/thermal/qcom/tsens-v2.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -44,7 +44,6 @@ static const struct reg_field tsens_v2_regfields[MAX_REGFIELDS] = {
 	/* CTRL_OFF */
 	[TSENS_EN]     = REG_FIELD(SROT_CTRL_OFF,    0,  0),
 	[TSENS_SW_RST] = REG_FIELD(SROT_CTRL_OFF,    1,  1),
-	[SENSOR_EN]    = REG_FIELD(SROT_CTRL_OFF,    3, 18),
 
 	/* ----- TM ------ */
 	/* INTERRUPT ENABLE */
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index 36b0b52..0627d86 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -85,11 +85,6 @@ static int tsens_register(struct tsens_priv *priv)
 	struct thermal_zone_device *tzd;
 
 	for (i = 0;  i < priv->num_sensors; i++) {
-		if (!is_sensor_enabled(priv, priv->sensor[i].hw_id)) {
-			dev_err(priv->dev, "sensor %d: disabled\n",
-				priv->sensor[i].hw_id);
-			continue;
-		}
 		priv->sensor[i].priv = priv;
 		priv->sensor[i].id = i;
 		tzd = devm_thermal_zone_of_sensor_register(priv->dev, i,
diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
index eefe384..2fd9499 100644
--- a/drivers/thermal/qcom/tsens.h
+++ b/drivers/thermal/qcom/tsens.h
@@ -315,7 +315,6 @@ void compute_intercept_slope(struct tsens_priv *priv, u32 *pt1, u32 *pt2, u32 mo
 int init_common(struct tsens_priv *priv);
 int get_temp_tsens_valid(struct tsens_priv *priv, int i, int *temp);
 int get_temp_common(struct tsens_priv *priv, int i, int *temp);
-bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id);
 
 /* TSENS target */
 extern const struct tsens_plat_data data_8960;
-- 
2.1.4


^ permalink raw reply related	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-05-29  2:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <5ce71d79.1c69fb81.dd0de.33cf@mx.google.com>
     [not found] ` <7hv9y01z85.fsf@baylibre.com>
2019-05-24  1:29   ` next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd) Stephen Boyd
2019-05-26 21:51     ` Amit Kucheria
2019-05-28 18:09       ` Andy Gross
     [not found]         ` <CAJ=6tTr4EaLLiavN+aRpU3JnJ5MuAtU-uer_8iLm7QMh6i4rAg@mail.gmail.com>
2019-05-29  1:06           ` Eduardo Valentin
2019-05-29  1:19             ` Andy Gross
2019-05-29  2:34               ` [PATCH 1/1] Revert "drivers: thermal: tsens: Add new operation to check if a sensor is enabled" Eduardo Valentin
2019-05-28 20:17       ` next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd) Kevin Hilman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.