[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2491f962-a8e1-44c4-8ff9-f8c3e58a2a39@notapiano>
Date: Wed, 5 Jun 2024 08:33:14 -0400
From: Nícolas F. R. A. Prado <nfraprado@...labora.com>
To: Chen-Yu Tsai <wenst@...omium.org>
Cc: linux-mediatek@...ts.infradead.org,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, kernel@...labora.com
Subject: Re: Probe failures on mt8183-kukui-jacuzzi-juniper-sku16
On Wed, Jun 05, 2024 at 04:01:06PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Jun 4, 2024 at 11:52 PM Nícolas F. R. A. Prado
> <nfraprado@...labora.com> wrote:
> >
> > Hi,
> >
> > We're monitoring the status of device probe on the
> > mt8183-kukui-jacuzzi-juniper-sku16 platform in KernelCI, and I thought it'd be
> > helpful to share the results.
> >
> > These are the current failures:
> >
> > * /soc/i2c@...09000/trackpad@15
> > * /soc/svs@...0bc00
> > * /thermal-sensor1
> > * /thermal-sensor2
> >
> > In more details:
> >
> > * /soc/i2c@...09000/trackpad@15: I believe this is a second source trackpad and
> > is thus waiting for the "platform/chrome: Introduce DT hardware prober" series
> > [1] to be merged before it can be handled. Although looks like there haven't
> > been updates to the series in a while.
>
> I've been working on other stuff and haven't had time to respin this series.
No worries, but it's good to know that that's the latest status and I didn't
miss something.
>
> Just to confirm, is the failure due to pinctrl conflicts when the trackpad
> variants probe asynchronously?
Yes:
[ 2.185408] input: hid-over-i2c 06CB:CDB5 Mouse as /devices/platform/soc/11009000.i2c/i2c-2/2-002c/0018:06CB:CDB5.0001/input/input2
[ 2.845044] mt8183-pinctrl 10005000.pinctrl: pin GPIO7 already requested by 2-002c; cannot claim for 2-0015
[ 2.854700] mt8183-pinctrl 10005000.pinctrl: error -EINVAL: pin-7 (2-0015)
[ 2.869503] mt8183-pinctrl 10005000.pinctrl: error -EINVAL: could not request pin 7 (GPIO7) from group GPIO7 on device pinctrl_paris
[ 2.894885] elan_i2c 2-0015: Error applying setting, reverse things back
>
[..]
> > * /thermal-sensor1, /thermal-sensor2: The following is reported:
> >
> > [ 2.813605] thermal_sys: Failed to find 'trips' node
> > [ 2.813611] thermal_sys: Failed to find trip points for thermal-sensor1 id=0
> > [ 2.813619] generic-adc-thermal thermal-sensor1: Thermal zone sensor register failed: -22
> > [ 2.813624] generic-adc-thermal thermal-sensor1: probe with driver generic-adc-thermal failed with error -22
> >
> > And the same for thermal-sensor2. So both are missing the required 'trips'
> > subnode.
>
> IIRC either the driver or the DT had comments saying "these zones don't
> need trip points". In that case maybe the driver should use
> thermal_tripless_zone_device_register() for them?
I believe you're thinking of the SoC thermal zones, which had trips added (and
the comment removed) in commit 978979409209 ("arm64: dts: mediatek: mt8183:
Refactor thermal zones"). But these are the kukui board thermal zones.
The thermal-zones dt-binding does describe the 'trips' node as required, so I
think the only option in this case is to add trips to them, or remove the
thermal zones altogether. I'm guessing the
thermal_tripless_zone_device_register() helper is meant for other thermal zones
that aren't described in the DT.
Thanks,
Nícolas
Powered by blists - more mailing lists