Re: [PATCH 3/4] sh: remove superhyway bus support

["Arnd Bergmann" <arnd@kernel.org>]

On Thu, Aug 3, 2023, at 10:44, John Paul Adrian Glaubitz wrote:
> On Thu, 2023-08-03 at 16:58 +0900, D. Jeff Dionne wrote:
>> On Aug 3, 2023, at 04:15, Arnd Bergmann <arnd@kernel.org> wrote:
>> > 
>> > From: Arnd Bergmann <arnd@arndb.de>
>> > 
>> > superhyway was only referenced on sh4-202, which is now gone, so remove it all as well.
>> > 
>> > I could find no trace of anything ever calling
>> > superhyway_register_driver(), not in the git history but also not on the web, so I assume this has never served any purpose on mainline kernels.
>> 
>> I don’t know, but I think it is fairly safe to assume that there were no superhyway implementations other than internal to SuperH Co (or Hitachi).  Probably not at ST either.
>> 
>> I think this board, and infrastructure, can go without affecting any actual (even historical) user.  If anyone wants further conformation that there are/were no users of this in the wild, raise a flag and I will find out.
>
> OK, I'll think about applying this series. The thing is, we're going to 
> convert SuperH
> to device trees anyways. We're waiting now Yoshinori to post a rebased 
> version of the
> patch series.

Applying this first should definitely help with the DT conversion,
especially not having to create a bus specific binding for superhyway
would help, as converting that to DT would be a complete rewrite
but also be untestable without drivers attaching to the bus.

I would also recommend trying to eliminate most of the SoC
support for chips that only support a reference board but no
products or known user of the reference board itself. While
a lot of the conversion could be done fairly mechanical, at
least the clk driver for each chip is a huge effort.

I looked at the clk conversion in the past, as this is not just
needed for the DT work, but also to remove CONFIG_HAVE_LEGACY_CLK.
The patch series I did a while ago renames the sh clk interfaces
to no longer conflict with COMMON_CLK, which should allow it
to coexist with a DT-enabled platform in the same kernel build.
Let me know if you'd like me to dig out and rebase that series,
it probably still applies and may help you here.

     Arnd