From: Rob Herring <robh+dt@kernel.org> To: Doug Anderson <dianders@chromium.org> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Chen-Yu Tsai <wenst@chromium.org>, Frank Rowand <frowand.list@gmail.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, Hsin-Yi Wang <hsinyi@chromium.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, andriy.shevchenko@linux.intel.com, Jiri Kosina <jikos@kernel.org>, linus.walleij@linaro.org, broonie@kernel.org, gregkh@linuxfoundation.org, hdegoede@redhat.com, james.clark@arm.com, james@equiv.tech, keescook@chromium.org, petr.tesarik.ext@huawei.com, rafael@kernel.org, tglx@linutronix.de, Jeff LaBundy <jeff@labundy.com>, linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Johan Hovold <johan@kernel.org> Subject: Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver Date: Wed, 15 Nov 2023 13:28:12 -0600 [thread overview] Message-ID: <CAL_Jsq+puq20EWkQg1RTs2zfmh4DGbqz1krp+19c=wPXnLT5dA@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=VUZy9DaZgKafSpXXopD5k8ExGSR97BjAqC5tupPoxNfQ@mail.gmail.com> On Fri, Nov 10, 2023 at 6:12 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Thu, Nov 9, 2023 at 5:52 AM Rob Herring <robh+dt@kernel.org> wrote: > > > > > > End of background from Doug's cover letter. > > > > > > I think that using "status" is not a good idea, I find that confusing. > > > > "status" is what defines a device's state in terms of enabled, > > present, available. That's exactly what we're expressing here. > > > > Now, I do not think we should be mixing the device class (e.g. > > touchscreen) into status. I said this on v1, but apparently that was > > not listened to. > > Interesting. I must have missed the "don't mix device class into > status" part. Do you have a link to your post about that? Maybe > there's other stuff I missed... Having the device class stuck at the > end there was at least part of my last post [1] which gathered no > response. https://lore.kernel.org/all/CAL_JsqKK0tjeXNv=a8L3k0AjhCa15XOq1tPWqVod9mycsKXJHg@mail.gmail.com/ "I would not combine the 2 things. Knowing the class/type of the device may be useful independent of your problem." > I think one of the reasons that I felt we needed to mux the device > class into status was that it was going to make the code a lot less > fragile. Everything I've seen indicates that you don't want us to > create a "HW prober" node that could be used to provide relevant > phandles for different classes of devices, so the "HW prober" code > needs to either search through the whole device tree for a status of > "failed-needs-probe" or needs to contain per-board, hardcoded, > fully-qualified paths. > > I don't think we want to include hardcoded, fully-qualified paths in > the code. That would mean that if someone changed a node name > somewhere in the path to one of the devices that we're dealing with > then it would break. Right, nothing should depend on the full path. That's not an ABI just like the device path in sysfs is not (despite what Android HALs do). > So if we're searching the whole device tree for "failed-needs-probe" > then we need to figure out which devices are related to each other. If > a given board has second sources for MIPI panels, touchscreens, and > trackpads then we need to know which of the "failed-needs-probe" > devices are trackpads, which are touchscreens, and which are MIPI > panels. Do you have any suggestions for how we should do that? Maybe > it was in some other thread that I missed? I guess we could have a > board-specific table mapping (compatible + node name + reg) to a > class, but that feels awkward. Node name is supposed to correspond to device class, so why not use that (no path or unit-address.) and nothing else (well, besides "status")? Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org> To: Doug Anderson <dianders@chromium.org> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Chen-Yu Tsai <wenst@chromium.org>, Frank Rowand <frowand.list@gmail.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, Hsin-Yi Wang <hsinyi@chromium.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, andriy.shevchenko@linux.intel.com, Jiri Kosina <jikos@kernel.org>, linus.walleij@linaro.org, broonie@kernel.org, gregkh@linuxfoundation.org, hdegoede@redhat.com, james.clark@arm.com, james@equiv.tech, keescook@chromium.org, petr.tesarik.ext@huawei.com, rafael@kernel.org, tglx@linutronix.de, Jeff LaBundy <jeff@labundy.com>, linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Johan Hovold <johan@kernel.org> Subject: Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver Date: Wed, 15 Nov 2023 13:28:12 -0600 [thread overview] Message-ID: <CAL_Jsq+puq20EWkQg1RTs2zfmh4DGbqz1krp+19c=wPXnLT5dA@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=VUZy9DaZgKafSpXXopD5k8ExGSR97BjAqC5tupPoxNfQ@mail.gmail.com> On Fri, Nov 10, 2023 at 6:12 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Thu, Nov 9, 2023 at 5:52 AM Rob Herring <robh+dt@kernel.org> wrote: > > > > > > End of background from Doug's cover letter. > > > > > > I think that using "status" is not a good idea, I find that confusing. > > > > "status" is what defines a device's state in terms of enabled, > > present, available. That's exactly what we're expressing here. > > > > Now, I do not think we should be mixing the device class (e.g. > > touchscreen) into status. I said this on v1, but apparently that was > > not listened to. > > Interesting. I must have missed the "don't mix device class into > status" part. Do you have a link to your post about that? Maybe > there's other stuff I missed... Having the device class stuck at the > end there was at least part of my last post [1] which gathered no > response. https://lore.kernel.org/all/CAL_JsqKK0tjeXNv=a8L3k0AjhCa15XOq1tPWqVod9mycsKXJHg@mail.gmail.com/ "I would not combine the 2 things. Knowing the class/type of the device may be useful independent of your problem." > I think one of the reasons that I felt we needed to mux the device > class into status was that it was going to make the code a lot less > fragile. Everything I've seen indicates that you don't want us to > create a "HW prober" node that could be used to provide relevant > phandles for different classes of devices, so the "HW prober" code > needs to either search through the whole device tree for a status of > "failed-needs-probe" or needs to contain per-board, hardcoded, > fully-qualified paths. > > I don't think we want to include hardcoded, fully-qualified paths in > the code. That would mean that if someone changed a node name > somewhere in the path to one of the devices that we're dealing with > then it would break. Right, nothing should depend on the full path. That's not an ABI just like the device path in sysfs is not (despite what Android HALs do). > So if we're searching the whole device tree for "failed-needs-probe" > then we need to figure out which devices are related to each other. If > a given board has second sources for MIPI panels, touchscreens, and > trackpads then we need to know which of the "failed-needs-probe" > devices are trackpads, which are touchscreens, and which are MIPI > panels. Do you have any suggestions for how we should do that? Maybe > it was in some other thread that I missed? I guess we could have a > board-specific table mapping (compatible + node name + reg) to a > class, but that feels awkward. Node name is supposed to correspond to device class, so why not use that (no path or unit-address.) and nothing else (well, besides "status")? Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-15 19:28 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-09 10:05 [RFC PATCH v2 0/7] of: Introduce hardware prober driver Chen-Yu Tsai 2023-11-09 10:05 ` Chen-Yu Tsai 2023-11-09 10:05 ` [RFC PATCH v2 1/7] of: base: Add of_device_is_fail Chen-Yu Tsai 2023-11-09 10:05 ` Chen-Yu Tsai 2023-11-09 10:05 ` [RFC PATCH v2 2/7] of: Introduce hardware prober driver Chen-Yu Tsai 2023-11-09 10:05 ` Chen-Yu Tsai 2023-11-09 15:13 ` Rob Herring 2023-11-09 15:13 ` Rob Herring 2023-11-14 8:30 ` Chen-Yu Tsai 2023-11-14 8:30 ` Chen-Yu Tsai 2023-11-09 17:54 ` Andy Shevchenko 2023-11-09 17:54 ` Andy Shevchenko 2023-11-14 8:26 ` Chen-Yu Tsai 2023-11-14 8:26 ` Chen-Yu Tsai 2023-11-09 10:06 ` [RFC PATCH v2 3/7] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-09 10:06 ` [RFC PATCH v2 4/7] arm64: dts: mediatek: mt8173-elm-hana: Add G2touch G7500 touchscreen Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-09 10:06 ` [RFC PATCH v2 5/7] of: hw_prober: Support Chromebook SKU ID based component selection Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-10 21:07 ` Rob Herring 2023-11-10 21:07 ` Rob Herring 2023-11-09 10:06 ` [RFC PATCH v2 6/7] dt-bindings: arm: mediatek: Remove SKU specific compatibles for Google Krane Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-10 21:04 ` Rob Herring 2023-11-10 21:04 ` Rob Herring 2023-11-11 0:29 ` Doug Anderson 2023-11-11 0:29 ` Doug Anderson 2023-11-09 10:06 ` [RFC PATCH v2 7/7] arm64: dts: mediatek: mt8183-kukui: Merge Krane device trees Chen-Yu Tsai 2023-11-09 10:06 ` Chen-Yu Tsai 2023-11-09 10:54 ` [RFC PATCH v2 0/7] of: Introduce hardware prober driver AngeloGioacchino Del Regno 2023-11-09 10:54 ` AngeloGioacchino Del Regno 2023-11-09 13:51 ` Rob Herring 2023-11-09 13:51 ` Rob Herring 2023-11-11 0:12 ` Doug Anderson 2023-11-11 0:12 ` Doug Anderson 2023-11-15 19:28 ` Rob Herring [this message] 2023-11-15 19:28 ` Rob Herring 2023-11-15 20:44 ` Doug Anderson 2023-11-15 20:44 ` Doug Anderson 2023-11-15 21:34 ` Rob Herring 2023-11-15 21:34 ` Rob Herring 2023-11-15 22:13 ` Doug Anderson 2023-11-15 22:13 ` Doug Anderson 2023-11-16 5:11 ` Chen-Yu Tsai 2023-11-16 5:11 ` Chen-Yu Tsai 2023-11-19 14:34 ` Rob Herring 2023-11-19 14:34 ` Rob Herring 2023-11-16 5:07 ` Chen-Yu Tsai 2023-11-16 5:07 ` Chen-Yu Tsai 2023-11-14 7:05 ` Chen-Yu Tsai 2023-11-14 7:05 ` Chen-Yu Tsai 2023-11-14 8:57 ` Chen-Yu Tsai 2023-11-14 8:57 ` Chen-Yu Tsai 2023-11-14 10:04 ` AngeloGioacchino Del Regno 2023-11-14 10:04 ` AngeloGioacchino Del Regno 2023-11-11 0:22 ` Doug Anderson 2023-11-11 0:22 ` Doug Anderson 2023-11-14 8:44 ` Chen-Yu Tsai 2023-11-14 8:44 ` Chen-Yu Tsai
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAL_Jsq+puq20EWkQg1RTs2zfmh4DGbqz1krp+19c=wPXnLT5dA@mail.gmail.com' \ --to=robh+dt@kernel.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=angelogioacchino.delregno@collabora.com \ --cc=broonie@kernel.org \ --cc=conor+dt@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=dianders@chromium.org \ --cc=dmitry.torokhov@gmail.com \ --cc=frowand.list@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=hdegoede@redhat.com \ --cc=hsinyi@chromium.org \ --cc=james.clark@arm.com \ --cc=james@equiv.tech \ --cc=jeff@labundy.com \ --cc=jikos@kernel.org \ --cc=johan@kernel.org \ --cc=keescook@chromium.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=matthias.bgg@gmail.com \ --cc=petr.tesarik.ext@huawei.com \ --cc=rafael@kernel.org \ --cc=tglx@linutronix.de \ --cc=wenst@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.