[PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Greg Kroah-Hartman]

On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote:
> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
> > On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
> >> On 10/11/23 08:48, Greg KH wrote:
> >> > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> >> >> 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 at 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.
> >
> >> 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.

As I reviewed that patch already, it is just duplicating an existing
quirk/device that the driver already supports, so there is no need for
any "new device type" to be added to that driver, just use the existing
hardware description in the dt and all should be fine.

thanks,

greg k-h