[PATCH 2/4] net: stmmac: Add Toshiba Visconti SoCs glue driver
Nobuhiro Iwamatsu
nobuhiro1.iwamatsu at toshiba.co.jp
Mon Feb 15 10:20:11 EST 2021
Hi,
On Mon, Feb 15, 2021 at 01:19:18PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 15, 2021 at 10:23 AM Leon Romanovsky <leon at kernel.org> wrote:
> > On Mon, Feb 15, 2021 at 04:28:09PM +0900, Nobuhiro Iwamatsu wrote:
> > >
> > > Sorry, I sent the wrong patchset that didn't fix this point out.
> > >
> > > > I asked it before, but never received an answer.
> > >
> > > I have received your point out and have sent an email with the content
> > > to remove this line. But it may not have arrived yet...
> > >
> > > > Why did you use "def_bool y" and not "default y"? Isn't it supposed to be
> > > > "depends on STMMAC_ETH"? And probably it shouldn't be set as a default as "y".
> > > >
> > >
> > > The reason why "def_bool y" was set is that the wrong fix was left when
> > > debugging. Also, I don't think it is necessary to set "default y".
> > > This is also incorrect because it says "bool" Toshiba Visconti DWMAC
> > > support "". I change it to trustate in the new patch.
> > >
> > > And this driver is enabled when STMMAC_PLATFORM was Y. And STMMAC_PLATFORM
> > > depends on STMMAC_ETH.
> > > So I understand that STMMAC_ETH does not need to be dependents. Is this
> > > understanding wrong?
> >
> > This is correct understanding, just need to clean other entries in that
> > Kconfig that depends on STMMAC_ETH.
>
> 'tristate' with no default sounds right. I see that some platforms have a
> default according to the platform, which also makes sense but isn't
> required. What I would suggest though is a dependency on the platform,
> to make it easier to disable the front-end based on which platforms
> are enabled. This would end up as
>
> config DWMAC_VISCONTI
> tristate "Toshiba Visconti DWMAC support"
> depends on ARCH_VISCONTI || COMPILE_TEST
> depends on OF && COMMON_CLK # only add this line if it's
> required for compilation
> default ARCH_VISCONTI
>
The fix at hand is the same as your suggestion.
Thank you for your comment.
> Arnd
>
Best regards,
Nobuhiro
More information about the linux-arm-kernel
mailing list