Message ID | 20200727204731.1705418-1-andrew@lunn.ch |
---|---|
Headers | show |
Series | Restructure drivers/net/phy | expand |
On Mon, 27 Jul 2020 22:47:28 +0200 Andrew Lunn wrote:
> RFC Because it needs 0-day build testing
Looks like allmodconfig falls over on patches 2 and 3.
make[6]: *** No rule to make target 'drivers/net/phy/phy/mscc/mscc_ptp.o', needed by 'drivers/net/phy/phy/mscc/mscc.o'. Stop.
On Mon, Jul 27, 2020 at 03:05:34PM -0700, Jakub Kicinski wrote: > On Mon, 27 Jul 2020 22:47:28 +0200 Andrew Lunn wrote: > > RFC Because it needs 0-day build testing > > Looks like allmodconfig falls over on patches 2 and 3. > > make[6]: *** No rule to make target 'drivers/net/phy/phy/mscc/mscc_ptp.o', needed by 'drivers/net/phy/phy/mscc/mscc.o'. Stop. Thanks Jakub. My desktop machine takes its time with allmodconfig builds. mscc_ptp.c & mscc_ptp.h got added after my first implementation. When i rebased they got left in there old location. I fixed it, and pushed my branch out. 0-day should run some tests on it. Lets see if it finds anything else. Andrew
> Subject: [PATCH RFC net-next 0/3] Restructure drivers/net/phy > > RFC Because it needs 0-day build testing > > The directory drivers/net/phy is getting rather cluttered with the growing > number of MDIO bus drivers and PHY device drivers. We also have one PCS > driver and more are expected soon. > > Restructure the directory, moving MDIO bus drivers into /mdio. PHY drivers into > /phy. The one current PCS driver is moved into /pcs and renamed to give it the > pcs- prefix which we hope will be followed by other PCS drivers. > I think that the MAINTAINERS file should also be updated to mention the new path to the drivers. Just did a quick grep after 'drivers/net/phy': F: drivers/net/phy/adin.c F: drivers/net/phy/mdio-xgene.c F: drivers/net/phy/ F: drivers/net/phy/marvell10g.c F: drivers/net/phy/mdio-mvusb.c F: drivers/net/phy/dp83640* F: drivers/net/phy/phylink.c F: drivers/net/phy/sfp* F: drivers/net/phy/mdio-xpcs.c Other than that, the new 'drivers/net/phy/phy/' path is somewhat repetitive but unfortunately I do not have another better suggestion. Ioana > Andrew Lunn (3): > net: xgene: Move shared header file into include/linux > net: phy: Move into subdirectories > net: phy: Move and rename mdio-xpcs > > .../net/ethernet/apm/xgene/xgene_enet_main.h | 2 +- > drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +- > drivers/net/ethernet/stmicro/stmmac/common.h | 2 +- > drivers/net/phy/Kconfig | 489 +----------------- > drivers/net/phy/Makefile | 79 +-- > drivers/net/phy/mdio/Kconfig | 226 ++++++++ > drivers/net/phy/mdio/Makefile | 26 + > drivers/net/phy/{ => mdio}/mdio-aspeed.c | 0 > drivers/net/phy/{ => mdio}/mdio-bcm-iproc.c | 0 > drivers/net/phy/{ => mdio}/mdio-bcm-unimac.c | 0 > drivers/net/phy/{ => mdio}/mdio-bitbang.c | 0 > drivers/net/phy/{ => mdio}/mdio-cavium.c | 0 > drivers/net/phy/{ => mdio}/mdio-cavium.h | 0 > drivers/net/phy/{ => mdio}/mdio-gpio.c | 0 > drivers/net/phy/{ => mdio}/mdio-hisi-femac.c | 0 > drivers/net/phy/{ => mdio}/mdio-ipq4019.c | 0 > drivers/net/phy/{ => mdio}/mdio-ipq8064.c | 0 > drivers/net/phy/{ => mdio}/mdio-moxart.c | 0 > drivers/net/phy/{ => mdio}/mdio-mscc-miim.c | 0 > .../net/phy/{ => mdio}/mdio-mux-bcm-iproc.c | 0 > drivers/net/phy/{ => mdio}/mdio-mux-gpio.c | 0 > .../net/phy/{ => mdio}/mdio-mux-meson-g12a.c | 0 > drivers/net/phy/{ => mdio}/mdio-mux-mmioreg.c | 0 > .../net/phy/{ => mdio}/mdio-mux-multiplexer.c | 0 > drivers/net/phy/{ => mdio}/mdio-mux.c | 0 > drivers/net/phy/{ => mdio}/mdio-mvusb.c | 0 > drivers/net/phy/{ => mdio}/mdio-octeon.c | 0 > drivers/net/phy/{ => mdio}/mdio-sun4i.c | 0 > drivers/net/phy/{ => mdio}/mdio-thunder.c | 0 > drivers/net/phy/{ => mdio}/mdio-xgene.c | 2 +- > drivers/net/phy/pcs/Kconfig | 20 + > drivers/net/phy/pcs/Makefile | 4 + > .../net/phy/{mdio-xpcs.c => pcs/pcs-xpcs.c} | 2 +- > drivers/net/phy/phy/Kconfig | 243 +++++++++ > drivers/net/phy/phy/Makefile | 50 ++ > drivers/net/phy/{ => phy}/adin.c | 0 > drivers/net/phy/{ => phy}/amd.c | 0 > drivers/net/phy/{ => phy}/aquantia.h | 0 > drivers/net/phy/{ => phy}/aquantia_hwmon.c | 0 > drivers/net/phy/{ => phy}/aquantia_main.c | 0 > drivers/net/phy/{ => phy}/at803x.c | 0 > drivers/net/phy/{ => phy}/ax88796b.c | 0 > drivers/net/phy/{ => phy}/bcm-cygnus.c | 0 > drivers/net/phy/{ => phy}/bcm-phy-lib.c | 0 > drivers/net/phy/{ => phy}/bcm-phy-lib.h | 0 > drivers/net/phy/{ => phy}/bcm54140.c | 0 > drivers/net/phy/{ => phy}/bcm63xx.c | 0 > drivers/net/phy/{ => phy}/bcm7xxx.c | 0 > drivers/net/phy/{ => phy}/bcm84881.c | 0 > drivers/net/phy/{ => phy}/bcm87xx.c | 0 > drivers/net/phy/{ => phy}/broadcom.c | 0 > drivers/net/phy/{ => phy}/cicada.c | 0 > drivers/net/phy/{ => phy}/cortina.c | 0 > drivers/net/phy/{ => phy}/davicom.c | 0 > drivers/net/phy/{ => phy}/dp83640.c | 0 > drivers/net/phy/{ => phy}/dp83640_reg.h | 0 > drivers/net/phy/{ => phy}/dp83822.c | 0 > drivers/net/phy/{ => phy}/dp83848.c | 0 > drivers/net/phy/{ => phy}/dp83867.c | 0 > drivers/net/phy/{ => phy}/dp83869.c | 0 > drivers/net/phy/{ => phy}/dp83tc811.c | 0 > drivers/net/phy/{ => phy}/et1011c.c | 0 > drivers/net/phy/{ => phy}/icplus.c | 0 > drivers/net/phy/{ => phy}/intel-xway.c | 0 > drivers/net/phy/{ => phy}/lxt.c | 0 > drivers/net/phy/{ => phy}/marvell.c | 0 > drivers/net/phy/{ => phy}/marvell10g.c | 0 > drivers/net/phy/{ => phy}/meson-gxl.c | 0 > drivers/net/phy/{ => phy}/micrel.c | 0 > drivers/net/phy/{ => phy}/microchip.c | 0 > drivers/net/phy/{ => phy}/microchip_t1.c | 0 > drivers/net/phy/{ => phy}/mscc/Makefile | 0 > drivers/net/phy/{ => phy}/mscc/mscc.h | 0 > .../net/phy/{ => phy}/mscc/mscc_fc_buffer.h | 0 > drivers/net/phy/{ => phy}/mscc/mscc_mac.h | 0 > drivers/net/phy/{ => phy}/mscc/mscc_macsec.c | 0 > drivers/net/phy/{ => phy}/mscc/mscc_macsec.h | 0 > drivers/net/phy/{ => phy}/mscc/mscc_main.c | 0 > drivers/net/phy/{ => phy}/national.c | 0 > drivers/net/phy/{ => phy}/nxp-tja11xx.c | 0 > drivers/net/phy/{ => phy}/qsemi.c | 0 > drivers/net/phy/{ => phy}/realtek.c | 0 > drivers/net/phy/{ => phy}/rockchip.c | 0 > drivers/net/phy/{ => phy}/smsc.c | 0 > drivers/net/phy/{ => phy}/ste10Xp.c | 0 > drivers/net/phy/{ => phy}/teranetics.c | 0 > drivers/net/phy/{ => phy}/uPD60620.c | 0 > drivers/net/phy/{ => phy}/vitesse.c | 0 > .../net/phy => include/linux}/mdio-xgene.h | 0 > include/linux/{mdio-xpcs.h => pcs-xpcs.h} | 8 +- > 90 files changed, 594 insertions(+), 561 deletions(-) create mode 100644 (...)
On Tue, Jul 28, 2020 at 03:42:22PM +0000, Ioana Ciornei wrote: > > Subject: [PATCH RFC net-next 0/3] Restructure drivers/net/phy > > > > RFC Because it needs 0-day build testing > > > > The directory drivers/net/phy is getting rather cluttered with the growing > > number of MDIO bus drivers and PHY device drivers. We also have one PCS > > driver and more are expected soon. > > > > Restructure the directory, moving MDIO bus drivers into /mdio. PHY drivers into > > /phy. The one current PCS driver is moved into /pcs and renamed to give it the > > pcs- prefix which we hope will be followed by other PCS drivers. > > > > Other than that, the new 'drivers/net/phy/phy/' path is somewhat repetitive but > unfortunately I do not have another better suggestion. There aren't many suitable names. The options I can think of are: drivers (but is still repetitive, or drv for a shortened version) media (since they're driving media facing PHYs) phy (as already suggested by Andrew) Nothing really stands out as a good choice.
> I think that the MAINTAINERS file should also be updated to mention the new > path to the drivers. Just did a quick grep after 'drivers/net/phy': > F: drivers/net/phy/adin.c > F: drivers/net/phy/mdio-xgene.c > F: drivers/net/phy/ > F: drivers/net/phy/marvell10g.c > F: drivers/net/phy/mdio-mvusb.c > F: drivers/net/phy/dp83640* > F: drivers/net/phy/phylink.c > F: drivers/net/phy/sfp* > F: drivers/net/phy/mdio-xpcs.c Hi Ioana Thanks, I will take care of that. > Other than that, the new 'drivers/net/phy/phy/' path is somewhat repetitive but > unfortunately I do not have another better suggestion. Me neither. I wonder if we are looking at the wrong part of the patch. drivers/net/X/phy/ drivers/net/X/mdio/ drivers/net/X/pcs/ Question is, what would X be? Andrew
> Subject: Re: [PATCH RFC net-next 0/3] Restructure drivers/net/phy > > > I think that the MAINTAINERS file should also be updated to mention > > the new path to the drivers. Just did a quick grep after 'drivers/net/phy': > > F: drivers/net/phy/adin.c > > F: drivers/net/phy/mdio-xgene.c > > F: drivers/net/phy/ > > F: drivers/net/phy/marvell10g.c > > F: drivers/net/phy/mdio-mvusb.c > > F: drivers/net/phy/dp83640* > > F: drivers/net/phy/phylink.c > > F: drivers/net/phy/sfp* > > F: drivers/net/phy/mdio-xpcs.c > > Hi Ioana > > Thanks, I will take care of that. > > > Other than that, the new 'drivers/net/phy/phy/' path is somewhat > > repetitive but unfortunately I do not have another better suggestion. > > Me neither. > > I wonder if we are looking at the wrong part of the patch. > drivers/net/X/phy/ > drivers/net/X/mdio/ > drivers/net/X/pcs/ > > Question is, what would X be? > > Andrew It may not be a popular suggestion but can't we take the drivers/net/phy, drivers/net/pcs and drivers/net/mdio route? Ioana
On 7/28/2020 9:28 AM, Ioana Ciornei wrote: >> Subject: Re: [PATCH RFC net-next 0/3] Restructure drivers/net/phy >> >>> I think that the MAINTAINERS file should also be updated to mention >>> the new path to the drivers. Just did a quick grep after 'drivers/net/phy': >>> F: drivers/net/phy/adin.c >>> F: drivers/net/phy/mdio-xgene.c >>> F: drivers/net/phy/ >>> F: drivers/net/phy/marvell10g.c >>> F: drivers/net/phy/mdio-mvusb.c >>> F: drivers/net/phy/dp83640* >>> F: drivers/net/phy/phylink.c >>> F: drivers/net/phy/sfp* >>> F: drivers/net/phy/mdio-xpcs.c >> >> Hi Ioana >> >> Thanks, I will take care of that. >> >>> Other than that, the new 'drivers/net/phy/phy/' path is somewhat >>> repetitive but unfortunately I do not have another better suggestion. >> >> Me neither. >> >> I wonder if we are looking at the wrong part of the patch. >> drivers/net/X/phy/ >> drivers/net/X/mdio/ >> drivers/net/X/pcs/ >> >> Question is, what would X be? >> >> Andrew > > It may not be a popular suggestion but can't we take the drivers/net/phy, > drivers/net/pcs and drivers/net/mdio route? > > Ioana > > > That sounds preferable to me as well. -Doug
On 7/28/2020 5:28 PM, Doug Berger wrote: > On 7/28/2020 9:28 AM, Ioana Ciornei wrote: >>> Subject: Re: [PATCH RFC net-next 0/3] Restructure drivers/net/phy >>> >>>> I think that the MAINTAINERS file should also be updated to mention >>>> the new path to the drivers. Just did a quick grep after 'drivers/net/phy': >>>> F: drivers/net/phy/adin.c >>>> F: drivers/net/phy/mdio-xgene.c >>>> F: drivers/net/phy/ >>>> F: drivers/net/phy/marvell10g.c >>>> F: drivers/net/phy/mdio-mvusb.c >>>> F: drivers/net/phy/dp83640* >>>> F: drivers/net/phy/phylink.c >>>> F: drivers/net/phy/sfp* >>>> F: drivers/net/phy/mdio-xpcs.c >>> >>> Hi Ioana >>> >>> Thanks, I will take care of that. >>> >>>> Other than that, the new 'drivers/net/phy/phy/' path is somewhat >>>> repetitive but unfortunately I do not have another better suggestion. >>> >>> Me neither. >>> >>> I wonder if we are looking at the wrong part of the patch. >>> drivers/net/X/phy/ >>> drivers/net/X/mdio/ >>> drivers/net/X/pcs/ >>> >>> Question is, what would X be? >>> >>> Andrew >> >> It may not be a popular suggestion but can't we take the drivers/net/phy, >> drivers/net/pcs and drivers/net/mdio route? +1
On Tue, Jul 28, 2020 at 05:34:44PM -0700, Florian Fainelli wrote: > > > On 7/28/2020 5:28 PM, Doug Berger wrote: > > On 7/28/2020 9:28 AM, Ioana Ciornei wrote: > >>> Subject: Re: [PATCH RFC net-next 0/3] Restructure drivers/net/phy > >>> > >>>> I think that the MAINTAINERS file should also be updated to mention > >>>> the new path to the drivers. Just did a quick grep after 'drivers/net/phy': > >>>> F: drivers/net/phy/adin.c > >>>> F: drivers/net/phy/mdio-xgene.c > >>>> F: drivers/net/phy/ > >>>> F: drivers/net/phy/marvell10g.c > >>>> F: drivers/net/phy/mdio-mvusb.c > >>>> F: drivers/net/phy/dp83640* > >>>> F: drivers/net/phy/phylink.c > >>>> F: drivers/net/phy/sfp* > >>>> F: drivers/net/phy/mdio-xpcs.c > >>> > >>> Hi Ioana > >>> > >>> Thanks, I will take care of that. > >>> > >>>> Other than that, the new 'drivers/net/phy/phy/' path is somewhat > >>>> repetitive but unfortunately I do not have another better suggestion. > >>> > >>> Me neither. > >>> > >>> I wonder if we are looking at the wrong part of the patch. > >>> drivers/net/X/phy/ > >>> drivers/net/X/mdio/ > >>> drivers/net/X/pcs/ > >>> > >>> Question is, what would X be? > >>> > >>> Andrew > >> > >> It may not be a popular suggestion but can't we take the drivers/net/phy, > >> drivers/net/pcs and drivers/net/mdio route? > > +1 O.K. Then let me see what happens to the core code. How easy it is to split up, or if it all need to be together, probably still in phy. Andrew