Re: [PATCH 05/11] dt-bindings: serio: add Arm PL050 DT schema

[Andre Przywara <andre.przywara@arm.com>]

On Fri, 29 Apr 2022 08:35:02 +0200
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

Hi Krzysztof,

> On 29/04/2022 08:29, Krzysztof Kozlowski wrote:
> > The driver is coming from ancient times, so it is understandable it has
> > some old coding style. But it definitely not sailed away. :)

What I meant with this was: there are DTs and drivers out there, for years
now, and this binding is just documenting that state.

I understand that in an ideal world you start with the binding, then write
drivers and DT based on that, but we missed that opportunity years ago.
It actually looks like this uppercase clock name predates the git history,
so this was probably the internal board file clock name twenty years ago,
and just got converted into the DT clock name.

> >> So by
> >> changing this we would break both the existing DT's compliance and also
> >> existing Linux kernels.
> >> So is lowercase something that is mandated by DT schema, or can we just
> >> make an exception here?  
> > 
> > This uppercase clock name affects even ARM64 devices, so it seems the
> > device is still being used. Therefore I propose to add new clock name,
> > old as deprecated and support both in the driver:
> > 
> > 	kmi->clk = clk_get(&dev->dev, "kmirefclk");
> > 	if (IS_ERR(kmi->clk)) {
> > 		kmi->clk = clk_get(&dev->dev, "KMIREFCLK");
> > 
> > and convert the DTS as well later on.  
> 
> On the other hand, I don't find this as that important if you do not
> have time for it, so I am fine with the exception and uppercase name.

Thanks, and yeah, I would really like to not change that. For once, this
device really doesn't have a big future (it's a PS/2 keyboard/mouse
controller after all), and the most prominent users are the fast models /
FVPs, where I wouldn't be aware of anyone actually using that device
there. (I don't even know how to do that). Other than that there is the
Juno board, but I need to disable the KMI driver there because it
electrically interferes with the USB PHY, so is not really usable there as
well, unless you sacrifice USB altogether.

So it would just create a lot of churn, for no real benefit.

Thanks!
Andre