[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200325070127.GA2960703@kroah.com>
Date: Wed, 25 Mar 2020 08:01:27 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Chunyan Zhang <zhang.lyra@...il.com>
Cc: Mark Rutland <mark.rutland@....com>, Jiri Slaby <jslaby@...e.com>,
"open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Orson Zhai <orsonzhai@...il.com>,
Baolin Wang <baolin.wang7@...il.com>,
Chunyan Zhang <chunyan.zhang@...soc.com>
Subject: Re: [PATCH] tty: serial: make SERIAL_SPRD depends on ARM or ARM64
On Wed, Mar 25, 2020 at 09:37:00AM +0800, Chunyan Zhang wrote:
> Hi Mark, Greg,
>
> Pleas see my answer below.
>
> On Tue, 24 Mar 2020 at 19:21, Mark Rutland <mark.rutland@....com> wrote:
> >
> > On Tue, Mar 24, 2020 at 02:49:49PM +0800, Chunyan Zhang wrote:
> > > From: Chunyan Zhang <chunyan.zhang@...soc.com>
> > >
> > > kbuild-test reported an error:
> > >
> > > config: mips-randconfig-a001-20200321 ...
> > > >> drivers/tty/serial/sprd_serial.c:1175: undefined reference
> > > to `clk_set_parent'
> > >
> > > Because some mips Kconfig-s select CONFIG_HAVE_CLK but not CONFIG_COMMON_CLK,
> > > so it's probably that clk_set_parent is missed for those configs.
> > >
> > > To fix this error, this patch adds dependence on ARM || ARM64
> > > for SERIAL_SPRD.
> >
> > From the above, isn't the real dependency COMMON_CLOCK?
>
> Some arch can implement its own clock APIs, for example AR7 [1].
That's fine, then they can not select this option.
> The sprd serial driver is used on ARM and ARM64 platforms only for
> now, which uses clock functions provided by COMMON_CLK, but it has the
> possibility of being used on other architecture platforms, that was my
> thought.
>
> I should revise this commit message to:
> "
> Because some mips Kconfig-s select CONFIG_HAVE_CLK but not define
> clk_set_parent which is used by the sprd serial driver.
> ...
> "
>
> Does it make sense?
The arch is not the issue here, the clock framework is, so properly
depend on that, not an arbitrary CPU type.
thanks,
greg k-h
Powered by blists - more mailing lists