On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:

On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:

quoted

On 10/11/23 08:48, Greg KH wrote:

quoted

On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:

quoted

Add dedicated google-gs101-uart compatible to the dt-schema for
representing uart of the Google Tensor gs101 SoC.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
 1 file changed, 2 insertions(+)

     oneOf:
       - items:
+          - const: google,gs101-uart
           - const: samsung,exynosautov9-uart
           - const: samsung,exynos850-uart
       - enum:
           - apple,s5l-uart
           - axis,artpec8-uart
+          - google,gs101-uart

These shouldn't be needed, just declare the device as the same as what

We should have SoC specific compatibles so that any further quirks or
incompatibilities can be easily addressed.

"further" work on quirks or incompatibilities can be added when they are
found and needed.  We don't add stuff for no good reason to the kernel.

quoted

It's not only the IP itself
that can differ, it's also the integration of the IP into the final
product that could have an influence on the behavior.

This is for the Pixel 6, a device that is no longer even shipping.  The
"final product" is long stable, so this should not be an issue.

The driver does have soc specific settings for each compatible
string, in this case it looks like it overrides the FIFO size
based on driver specific data and the order in which the
ports are probed [1]. I don't understand why the driver does
this, but my impression is that if we wanted to change it to no
longer rely on that data, we'd also need a new compatible
string.

Ideally, the actual compatible list in the DTB lists both the
specific implementation (google,gs101-uart) in order to allow
such hacks if needed, and a more generic string (e.g. 
"samsung,exynos850-uart" for an older device that is entirely
compatible) in order to not actually need driver changes.

      Arnd

[1] https://lore.kernel.org/linux-arm-kernel/20231010224928.2296997-17-peter.griffin@linaro.org/ (local)