From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Robin van der Gracht <robin@protonic.nl>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
Raul E Rangel <rrangel@chromium.org>,
Wolfram Sang <wsa@kernel.org>,
linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-usb@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v1 2/3] auxdisplay: ht16k33: Make use of device_get_match_data()
Date: Wed, 22 Feb 2023 21:11:05 +0200 [thread overview]
Message-ID: <Y/ZoyaV10TCWhloT@smile.fi.intel.com> (raw)
In-Reply-To: <06f29d66-f16a-039c-ecd0-155bdcce00c1@linaro.org>
On Wed, Feb 22, 2023 at 07:46:25PM +0100, Krzysztof Kozlowski wrote:
> On 22/02/2023 18:20, Andy Shevchenko wrote:
> >>
> >>> Which effectively breaks i.e. user-space instantiation for other display
> >>> types which now do work due to i2c_of_match_device().
> >>> (so my suggestion above is not sufficient).
> >>>
> >>> Are you proposing extending and searching the I2C ID table to work around
> >>> that?
> >>
> >> See (1) above. This is the downside I have noticed after sending this series.
> >> So, the I²C ID table match has to be restored, but the above mentioned issues
> >> with existing table are not gone, hence they need to be addressed in the next
> >> version.
> >
> > I see now what you mean. So, we have even more issues in this driver:
> > - I²C table is not in sync with all devices supported
>
> Does anything actually rely on i2c_device_id table? ACPI would match
> either via ACPI or OF tables. All modern ARM systems (e.g. imx6) are
> DT-based. Maybe just drop the I2C ID table?
For I²C it's still possible to enumerate the device via sysfs, which is ABI.
> > - the OF ID table seems has something really badly formed for adafruit
> > (just a number after a comma)
>
> Maybe it is a model number? It was documented:
> Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
Yes, it's not a problem for ACPI/DT platforms, the problem is for the above
way of enumeration, so if we have more than 1 manufacturer that uses plain
numbers for the model, I²C framework may not distinguish which driver to use.
I.o.w. the part after comma in the compatible strings of the I²C devices must
be unique globally to make that enumeration disambiguous.
> > The latter shows how broken it is. The I²C ID table mechanism is used as
> > a backward compatibility to the OF. Unfortunately, user space may not provide
> > the data except in form of DT overlays, so for the legacy enumeration we
> > have only device name, which is a set of 4 digits for adafruit case.
> >
> > Now imagine if by some reason we will get adafruit2 (you name it) with
> > the same schema. How I²C framework can understand that you meant adafruit
> > and not adafruit2? Or did I miss something?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-02-22 19:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 13:33 [PATCH v1 0/3] i2c: stop using i2c_of_match_device() Andy Shevchenko
2023-02-21 13:33 ` [PATCH v1 1/3] usb: typec: stusb160x: Make use of device_get_match_data() Andy Shevchenko
2023-02-21 13:53 ` Heikki Krogerus
2023-02-21 13:33 ` [PATCH v1 2/3] auxdisplay: ht16k33: " Andy Shevchenko
2023-02-21 13:40 ` Andy Shevchenko
2023-02-21 16:10 ` Robin van der Gracht
2023-02-21 17:48 ` Andy Shevchenko
2023-02-22 16:46 ` Robin van der Gracht
2023-02-22 17:01 ` Andy Shevchenko
2023-02-22 17:20 ` Andy Shevchenko
2023-02-22 18:46 ` Krzysztof Kozlowski
2023-02-22 19:11 ` Andy Shevchenko [this message]
2023-02-23 9:55 ` Geert Uytterhoeven
2023-02-23 11:53 ` Andy Shevchenko
2023-02-23 8:19 ` Robin van der Gracht
2023-02-21 13:33 ` [PATCH v1 3/3] i2c: Unexport i2c_of_match_device() Andy Shevchenko
2023-02-23 13:50 ` [PATCH v1 0/3] i2c: stop using i2c_of_match_device() Andy Shevchenko
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=Y/ZoyaV10TCWhloT@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robh+dt@kernel.org \
--cc=robin@protonic.nl \
--cc=rrangel@chromium.org \
--cc=wsa@kernel.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: link
Be 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.