Re: linux-next: build failure after merge of the phy-next tree

[Vinod Koul <vkoul@kernel.org>]

On 01-12-20, 07:45, Sergio Paracuellos wrote:
> Hi Stephen,
> 
> On Tue, Dec 1, 2020 at 7:07 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the phy-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/phy/ralink/phy-mt7621-pci.c:17:10: fatal error: mt7621.h: No such file or directory
> >    17 | #include <mt7621.h>
> >       |          ^~~~~~~~~~
> >
> > Caused by commit
> >
> >   d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY")
> 
> This driver has two includes which are in
> "arch/mips/include/asm/mach-ralink" and are directly included in the
> driver:
> * mt7621.h
> * ralink_regs.h
> 
> This is because this path is directly included in
> arch/mips/ralink/Platform for "ralink":
> 
> #
> # Ralink SoC common stuff
> #
> cflags-$(CONFIG_RALINK)     += -I$(srctree)/arch/mips/include/asm/mach-ralink
> 
> and this driver directly depends on RALINK or COMPILE_TEST (which
> might be the problem here):
> 
> 
> and this driver directly depends
> on RALINK or COMPILE_TEST:
> 
> config PHY_MT7621_PCI
>     tristate "MediaTek MT7621 PCI PHY Driver"
>     depends on (RALINK || COMPILE_TEST) && OF
>     select GENERIC_PHY
>     select REGMAP_MMIO
>     help
>       Say 'Y' here to add support for MediaTek MT7621 PCI PHY driver
> 
> >
> > I have reverted that commit for today.
> 
> What is the correct way of fixing this? Include complete path for both
> of them like this?
> 
> index db79088d5362..cebd53f5a797 100644
> --- a/drivers/phy/ralink/phy-mt7621-pci.c
> +++ b/drivers/phy/ralink/phy-mt7621-pci.c
> @@ -14,8 +14,8 @@
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
>  #include <linux/sys_soc.h>
> -#include <mt7621.h>
> -#include <ralink_regs.h>
> +#include <asm/mach-ralink/mt7621.h>
> +#include <asm/mach-ralink/ralink_regs.h>
> 
> Vinod, please let me know if you want me to send anything for fixing this.

Yes this makes sense. this will ensure it gets picked up and doesn't
depend in arch specific stuff

-- 
~Vinod