[PATCH] Nokia RX-51: Convert to CONFIG_DM_KEYBOARD

[Pali Rohár]

On Thursday 03 February 2022 15:10:58 Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 3 Feb 2022 at 15:09, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Feb 03, 2022 at 03:03:21PM -0700, Simon Glass wrote:
> > > Hi,
> > >
> > > On Thu, 3 Feb 2022 at 15:02, Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Thu, 3 Feb 2022 at 14:53, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
> > > > > > On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
> > > > > > > On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
> > > > > > >
> > > > > > > > Signed-off-by: Pali Rohár <pali at kernel.org>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > I would really appreciate if U-Boot test framework starts printing
> > > > > > > > deprecation warnings, instead of sending patches which directly drop
> > > > > > > > support for some boards.
> > > > > > > >
> > > > > > > > There is absolutely no warning during building U-Boot for RX-51 board
> > > > > > > > that this board has not been converted to DM_KEYBOARD yet.
> > > > > > >
> > > > > > > Please send some patch that implements what you're wanting to see for
> > > > > > > how to make the warnings more visible.  I do agree the warning for
> > > > > > > v2022.10 only showed up after the merge to -next once v2022.01 came out,
> > > > > > > but it's still a fairly long time to clean up the few unconverted
> > > > > > > boards.
> > > > > >
> > > > > > Oh, I see what's going on.  Simon, the DM_KEYBOARD check isn't
> > > > > > triggering for any boards.  I'll look more.
> > > > >
> > > > > And here's where we're at.  nokia_rx51 doesn't set CONFIG_KEYBOARD, so
> > > > > didn't trigger the warning about  migration.  Every platform that sets
> > > > > CONFIG_KEYBOARD is migrated.  I don't know how many other platforms are
> > > > > in the situation nokia_rx51 is in.  Yanking out the legacy code and
> > > > > seeing what fails to build, and going from there is probably the next
> > > > > option.
> > > >
> > > > Yes.
> > > >
> > > > As to your questoin, none that I know of. I sent a series to drop
> > > > cfb_console which was how this used to work, although in fact it
> > > > hasn't worked for a while. The problem here seems to be that this
> > > > board was multiple migrations behind and so was not caught.
> > > >
> > > > We should be able to remove the migration check.
> > > >
> > > > Pali, just to explain from the other POV, I am finding it increasingly
> > > > frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We
> > > > really need to complete some of the migrations we started 6 years ago.
> > >
> > > BTW the keyboard driver should go in drivers/input and should use
> > > device tree, not platdata.
> >
> > This is likely one of the cases where we end up saying a platform is
> > only platdata, given size concerns?  That's my quick recollection from
> > talking about the USB stuff a few months back, and some other related
> > size questions.
> 
> OK, I see. Yes, device tree would add a lot (in fact it doesn't even
> use OF_CONTROL).
> 
> Regards,
> Simon

Yes, there is no OF_CONTROL, no device tree, just plat data, because all
those options eats too many space... There was already discussion about
it in past and it is not possible to do anything with it.

As keyboard support was in board code before, I let it in board code as
I do not see any value to move this code into drivers/input as it is
board specific.