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@xxxxxxxxxx>
>> >> ---
>> >> 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.
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@xxxxxxxxxx/
