From: Chen-Yu Tsai <wenst@chromium.org> To: Doug Anderson <dianders@chromium.org> Cc: Rob Herring <robh+dt@kernel.org>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, 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, 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: Thu, 16 Nov 2023 13:11:26 +0800 [thread overview] Message-ID: <CAGXv+5E6zYBoiVr4oNQ9LHEgMWBjz4kBNv+sWmRa5_0jEkdUDg@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=XO5VNuaVKwBHLQC1ukdpHQO0-XTaKnRM=rigbcdOytgQ@mail.gmail.com> On Thu, Nov 16, 2023 at 6:14 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Nov 15, 2023 at 4:35 PM Rob Herring <robh+dt@kernel.org> wrote: > > > > On Wed, Nov 15, 2023 at 2:45 PM Doug Anderson <dianders@chromium.org> wrote: > > > > > > Hi, > > > > > > On Wed, Nov 15, 2023 at 2:28 PM Rob Herring <robh+dt@kernel.org> wrote: > > > > > > > > > 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")? > > > > > > One problem is that I could imagine having two second source trackpads > > > that both have the same i2c address. That would give them the same > > > name, right? I guess you could maybe come up with some sort of suffix > > > rule? Like > > > > > > trackpad-1@10 { > > > compatible = "elan,blah"; > > > ret = <0x10>; > > > status = "failed-needs-probe"; > > > ... > > > } > > > trackpad-2@10 { > > > compatible = "goodix,gt7375p"; > > > ret = <0x10>; > > > status = "failed-needs-probe"; > > > ... > > > } > > > > > > Then I guess the class would be "trackpad"? > > > > That issue is somewhat orthogonal because it is not following the spec. > > I'm not sure why you say it's orthogonal. The whole reason why we get > into the situation above is that we could have two devices, only one > of which is present (hence the status of "failed-needs-probe"), that > are the same type and have the same "reg" address. > > Essentially the whole "failed-needs-probe" is extending the spec, > right? While extending the spec, we also need to talk about what to do > if some of the devices that we need to probe have the same class and > the same "reg". If it's at the same address, then you would need some device specific probing code, like reading a register back and checking if matches some known value. This could be done by passing in some kind of table, but it is by no means as generic as checking if an address responds. This is what we have on MT8186 Tentacruel. We do have the ability to differentiate using the SKU ID for the same address case, but I'm happy to try other methods if it helps everyone else. ChenYu > > I'm not sure mixing the 2 styles of node names is a good idea. While > > not used too much, matching by node name does ignore the unit-address, > > but I'm not sure we could ignore a '-N'. > > > > I think our options are either add something to the unit-address or > > use i2c-mux binding. Adding to the unit-address is not unprecedented. > > I did that for some of the register bit level bindings where you have > > a node for different bits at the same address. The downside is > > unit-address is bus specific, so we'd have to add that for multiple > > buses. For the i2c-mux, it's perhaps a bit complex and I'm not sure > > what if anything you'd have to do to manage the mux that's not really > > there. > > Somehow it feels weird to use an i2c-mux because there's no real mux > present, right? ...so this would be a virtual (bogus) device that > doesn't really exist in hardware. > > ...though I guess if the "mux" type binding is OK then maybe we just > use that as the HW prober, at least for i2c devices... > > -Doug
WARNING: multiple messages have this Message-ID (diff)
From: Chen-Yu Tsai <wenst@chromium.org> To: Doug Anderson <dianders@chromium.org> Cc: Rob Herring <robh+dt@kernel.org>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, 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, 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: Thu, 16 Nov 2023 13:11:26 +0800 [thread overview] Message-ID: <CAGXv+5E6zYBoiVr4oNQ9LHEgMWBjz4kBNv+sWmRa5_0jEkdUDg@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=XO5VNuaVKwBHLQC1ukdpHQO0-XTaKnRM=rigbcdOytgQ@mail.gmail.com> On Thu, Nov 16, 2023 at 6:14 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Nov 15, 2023 at 4:35 PM Rob Herring <robh+dt@kernel.org> wrote: > > > > On Wed, Nov 15, 2023 at 2:45 PM Doug Anderson <dianders@chromium.org> wrote: > > > > > > Hi, > > > > > > On Wed, Nov 15, 2023 at 2:28 PM Rob Herring <robh+dt@kernel.org> wrote: > > > > > > > > > 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")? > > > > > > One problem is that I could imagine having two second source trackpads > > > that both have the same i2c address. That would give them the same > > > name, right? I guess you could maybe come up with some sort of suffix > > > rule? Like > > > > > > trackpad-1@10 { > > > compatible = "elan,blah"; > > > ret = <0x10>; > > > status = "failed-needs-probe"; > > > ... > > > } > > > trackpad-2@10 { > > > compatible = "goodix,gt7375p"; > > > ret = <0x10>; > > > status = "failed-needs-probe"; > > > ... > > > } > > > > > > Then I guess the class would be "trackpad"? > > > > That issue is somewhat orthogonal because it is not following the spec. > > I'm not sure why you say it's orthogonal. The whole reason why we get > into the situation above is that we could have two devices, only one > of which is present (hence the status of "failed-needs-probe"), that > are the same type and have the same "reg" address. > > Essentially the whole "failed-needs-probe" is extending the spec, > right? While extending the spec, we also need to talk about what to do > if some of the devices that we need to probe have the same class and > the same "reg". If it's at the same address, then you would need some device specific probing code, like reading a register back and checking if matches some known value. This could be done by passing in some kind of table, but it is by no means as generic as checking if an address responds. This is what we have on MT8186 Tentacruel. We do have the ability to differentiate using the SKU ID for the same address case, but I'm happy to try other methods if it helps everyone else. ChenYu > > I'm not sure mixing the 2 styles of node names is a good idea. While > > not used too much, matching by node name does ignore the unit-address, > > but I'm not sure we could ignore a '-N'. > > > > I think our options are either add something to the unit-address or > > use i2c-mux binding. Adding to the unit-address is not unprecedented. > > I did that for some of the register bit level bindings where you have > > a node for different bits at the same address. The downside is > > unit-address is bus specific, so we'd have to add that for multiple > > buses. For the i2c-mux, it's perhaps a bit complex and I'm not sure > > what if anything you'd have to do to manage the mux that's not really > > there. > > Somehow it feels weird to use an i2c-mux because there's no real mux > present, right? ...so this would be a virtual (bogus) device that > doesn't really exist in hardware. > > ...though I guess if the "mux" type binding is OK then maybe we just > use that as the HW prober, at least for i2c devices... > > -Doug _______________________________________________ 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-16 5:11 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 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 [this message] 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=CAGXv+5E6zYBoiVr4oNQ9LHEgMWBjz4kBNv+sWmRa5_0jEkdUDg@mail.gmail.com \ --to=wenst@chromium.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=rafael@kernel.org \ --cc=robh+dt@kernel.org \ --cc=tglx@linutronix.de \ /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.