* RE: [PATCH 2/2] net: phy: Associate device node with fixed PHY
From: Madalin Bucur (OSS) @ 2020-08-03 14:33 UTC (permalink / raw)
To: Andrew Lunn, Madalin Bucur (OSS)
Cc: Russell King - ARM Linux admin, Vikas Singh, f.fainelli@gmail.com,
hkallweit1@gmail.com, netdev@vger.kernel.org,
Calvin Johnson (OSS), kuldip dwivedi, Vikas Singh
In-Reply-To: <20200803125742.GK1862409@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 03 August 2020 15:58
> To: Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>
> Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>; Vikas Singh
> <vikas.singh@puresoftware.com>; f.fainelli@gmail.com; hkallweit1@gmail.com;
> netdev@vger.kernel.org; Calvin Johnson (OSS) <calvin.johnson@oss.nxp.com>;
> kuldip dwivedi <kuldip.dwivedi@puresoftware.com>; Vikas Singh
> <vikas.singh@nxp.com>
> Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
>
> > I see you agree that there were and there will be many changes for a
> while,
> > It's not a complaint, I know hot it works, it's just a decision based on
> > required effort vs features offered vs user requirements. Lately it's
> been
> > time consuming to try to fix things in this area.
>
> So the conclusion to all this that you are unwilling to use the
> correct API for this, which would be phylink, and the SFP code. So:
>
> NACK
>
> Andrew
You've rejected a generic change - ACPI support for fixed link.
The discussion above is just an example of how it could have been (mis-)used.
Are you rejecting the general case or just the particular one?
Madalin
^ permalink raw reply
* Re: [PATCH v2 net-next 03/11] sfc_ef100: read Design Parameters at probe time
From: Edward Cree @ 2020-08-03 14:33 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: linux-net-drivers, davem, netdev
In-Reply-To: <20200731131857.41b0f32a@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 31/07/2020 21:18, Jakub Kicinski wrote:
> On Fri, 31 Jul 2020 13:58:35 +0100 Edward Cree wrote:
>> + default:
>> + /* Host interface says "Drivers should ignore design parameters
>> + * that they do not recognise."
>> + */
>> + netif_info(efx, probe, efx->net_dev,
>> + "Ignoring unrecognised design parameter %u\n",
>> + reader->type);
> Is this really important enough to spam the logs with?
Well, it implies your NIC (FPGA image) is newer than your driver,
and saying things the driver doesn't understand; I feel like that
should be recorded somewhere.
Maybe this should be a netif_dbg() instead? (Or is this a subtle
way of telling me "you should implement devlink health"?)
> Should you warn if the TLV stream ends half-way through an entry?
Fair point, yes we should.
-ed
^ permalink raw reply
* Re: [PATCH] tools/bpf/bpftool: Fix wrong return value in do_dump()
From: Daniel Borkmann @ 2020-08-03 14:33 UTC (permalink / raw)
To: Tianjia Zhang, ast, kafai, songliubraving, yhs, andriin,
john.fastabend, kpsingh, quentin, kuba, toke, tklauser, jolsa
Cc: netdev, bpf, linux-kernel, tianjia.zhang
In-Reply-To: <20200802111540.5384-1-tianjia.zhang@linux.alibaba.com>
On 8/2/20 1:15 PM, Tianjia Zhang wrote:
> In case of btf_id does not exist, a negative error code -ENOENT
> should be returned.
>
> Fixes: c93cc69004df3 ("bpftool: add ability to dump BTF types")
> Cc: Andrii Nakryiko <andriin@fb.com>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Applied, thanks!
^ permalink raw reply
* Re: PMTUD broken inside network namespace with multipath routing
From: mastertheknife @ 2020-08-03 14:24 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <c508eeba-c62d-e4d9-98e2-333c76c90161@gmail.com>
Hi David,
In this case, both paths are in the same layer2 network, there is no
symmetric multi-path routing.
If original message takes path 1, ICMP response will come from path 1
If original message takes path 2, ICMP response will come from path 2
Also, It works fine outside of LXC.
Thank you,
Kfir
On Mon, Aug 3, 2020 at 4:32 PM David Ahern <dsahern@gmail.com> wrote:
>
> On 8/3/20 5:14 AM, mastertheknife wrote:
> > What seems to be happening, is that when multipath routing is used
> > inside LXC (or any network namespace), the kernel doesn't generate a
> > routing exception to force the lower MTU.
> > I believe this is a bug inside the kernel.
> >
>
> Known problem. Original message can take path 1 and ICMP message can
> path 2. The exception is then created on the wrong path.
^ permalink raw reply
* RE: [PATCH net-next] Add Mellanox BlueField Gigabit Ethernet driver
From: Asmaa Mnebhi @ 2020-08-03 14:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Thompson, netdev@vger.kernel.org, davem@davemloft.net,
kuba@kernel.org, Jiri Pirko
In-Reply-To: <20200801011454.GB1843538@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Friday, July 31, 2020 9:15 PM
> To: Asmaa Mnebhi <Asmaa@mellanox.com>
> Cc: David Thompson <dthompson@mellanox.com>;
> netdev@vger.kernel.org; davem@davemloft.net; kuba@kernel.org; Jiri Pirko
> <jiri@mellanox.com>
> Subject: Re: [PATCH net-next] Add Mellanox BlueField Gigabit Ethernet driver
>
> > > > > +static int mlxbf_gige_mdio_read(struct mii_bus *bus, int
> > > > > +phy_add, int
> > > >
> > > > > +phy_reg) {
> > > >
> > > > > + struct mlxbf_gige *priv = bus->priv;
> > > >
> > > > > + u32 cmd;
> > > >
> > > > > + u32 ret;
> > > >
> > > > > +
> > > >
> > > > > + /* If the lock is held by something else, drop the request.
> > > >
> > > > > + * If the lock is cleared, that means the busy bit was cleared.
> > > >
> > > > > + */
> > > >
> > > >
> > > >
> > > > How can this happen? The mdio core has a mutex which prevents
> > > > parallel
> > > access?
> > > >
> > > >
> > > >
> > > > This is a HW Lock. It is an actual register. So another HW entity
> > > > can be holding that lock and reading/changing the values in the HW
> registers.
> > >
> > > You have not explains how that can happen? Is there something in the
> > > driver i missed which takes a backdoor to read/write MDIO transactions?
> >
> > Ah ok! There is a HW entity (called YU) within the BlueField which is
> connected to the PHY device.
> > I think the YU is what you are calling "backdoor" here. The YU
> > contains several registers which control reads/writes To the PHY. So
> > it is like an extra layer for reading MDIO registers. One of the YU registers is
> the gateway register (aka GW or MLXBF_GIGE_MDIO_GW_OFFSET in the
> code). If the GW register's LOCK bit is not cleared, we cannot write anything
> to the actual PHY MDIO registers.
> > Did I answer your question?
>
> Nope.
>
> How can two transactions happen at the same time, causing this lock bit to
> be locked? Given that the MDIO core has a mutex and serialises all
> transactions. How can the lock bit every be set?
Ah I see what you are saying. SW takes care of it, so HW would never fall into this scenario. That will make things cleaner and faster then! Ok will change it, test it and report back.
>
> > > > > + ret = mlxbf_gige_mdio_poll_bit(priv,
> > > > > + MLXBF_GIGE_MDIO_GW_LOCK_MASK);
> > > >
> > > > > + if (ret)
> > > >
> > > > > + return -EBUSY;
> > > >
> > > >
> > > >
> > > > PHY drivers are not going to like that. They are not going to retry.
> > > > What is likely to happen is that phylib moves into the ERROR
> > > > state, and the PHY driver grinds to a halt.
> > > >
> > > >
> > > >
> > > > This is a fairly quick HW transaction. So I don’t think it would
> > > > cause and issue for the PHY drivers. In this case, we use the
> > > > micrel KSZ9031. We haven’t seen issues.
> > >
> > > So you have happy to debug hard to find and reproduce issues when it
> > > does happen? Or would you like to spend a little bit of time now and
> > > just prevent it happening at all?
> >
> > I think I misunderstood your comment. Did you ask why we are polling
> here? Or that we shouldn't be returning -EBUSY?
>
> I think you should not be returning EBUSY. If it every happens, bad things will
> happen.
>
> This lock bit seems to server no purpose. Software will ensure that
> transactions are serialized. If it serves no purpose, just ensure it is unlocked
> at probe time, and then ignore it. If you ignore it, you will never return -
> EBUSY and so bad things will never happen.
>
> Just because hardware exists does not mean you have to use it or that it
> adds any value.
Sounds good.
>
> Andrew
^ permalink raw reply
* Re: [PATCH bpf-next] tools build: propagate build failures from tools/build/Makefile.build
From: Daniel Borkmann @ 2020-08-03 14:18 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast
Cc: andrii.nakryiko, kernel-team, Jiri Olsa, Arnaldo Carvalho de Melo
In-Reply-To: <20200731024244.872574-1-andriin@fb.com>
On 7/31/20 4:42 AM, Andrii Nakryiko wrote:
> The '&&' command seems to have a bad effect when $(cmd_$(1)) exits with
> non-zero effect: the command failure is masked (despite `set -e`) and all but
> the first command of $(dep-cmd) is executed (successfully, as they are mostly
> printfs), thus overall returning 0 in the end.
>
> This means in practice that despite compilation errors, tools's build Makefile
> will return success. We see this very reliably with libbpf's Makefile, which
> doesn't get compilation error propagated properly. This in turns causes issues
> with selftests build, as well as bpftool and other projects that rely on
> building libbpf.
>
> The fix is simple: don't use &&. Given `set -e`, we don't need to chain
> commands with &&. The shell will exit on first failure, giving desired
> behavior and propagating error properly.
>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Fixes: 275e2d95591e ("tools build: Move dependency copy into function")
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH RFC net-next 2/3] net: phy: Move into subdirectories
From: Andrew Lunn @ 2020-08-03 14:15 UTC (permalink / raw)
To: Madalin Bucur (OSS)
Cc: netdev, Ioana Ciornei, Florian Fainelli, Russell King,
Heiner Kallweit
In-Reply-To: <AM6PR04MB3976B8E1672E74D127BAD833EC4D0@AM6PR04MB3976.eurprd04.prod.outlook.com>
On Mon, Aug 03, 2020 at 02:11:10PM +0000, Madalin Bucur (OSS) wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> > Behalf Of Andrew Lunn
> > Sent: 27 July 2020 23:48
> > To: netdev <netdev@vger.kernel.org>
> > Cc: Ioana Ciornei <ioana.ciornei@nxp.com>; Florian Fainelli
> > <f.fainelli@gmail.com>; Russell King <rmk+kernel@armlinux.org.uk>; Heiner
> > Kallweit <hkallweit1@gmail.com>; Andrew Lunn <andrew@lunn.ch>
> > Subject: [PATCH RFC net-next 2/3] net: phy: Move into subdirectories
> >
> > Move the PHY drivers into the phy subdirectory
>
> We could keep the PHY drivers in the base drivers/net/phy/ folder, move
> only mdio to introduce lesser changes.
Hi Madalin
Please trim irrelevant text when replying.
If you keep reading in this thread, you will see this suggestion has
been made by others. I've got an implementation which moved MDIO and
PCS drivers into new directories. But it has a few 0-day issues at the
moment, so i don't know if i will get it ready before David closes
net-next.
Andrew
^ permalink raw reply
* Re: [PATCH net-next RFC 01/13] devlink: Add reload level option to devlink reload command
From: Jiri Pirko @ 2020-08-03 14:14 UTC (permalink / raw)
To: Moshe Shemesh
Cc: Jakub Kicinski, Jacob Keller, netdev, linux-kernel,
David S. Miller, Jiri Pirko, Vasundhara Volam
In-Reply-To: <0f2467fd-ee2e-1a51-f9c1-02f8a579d542@mellanox.com>
Sat, Aug 01, 2020 at 11:32:25PM CEST, moshe@mellanox.com wrote:
>
>On 7/31/2020 2:11 AM, Jakub Kicinski wrote:
>> On Thu, 30 Jul 2020 15:30:45 +0300 Moshe Shemesh wrote:
>> > > > > My expectations would be that the driver must perform the lowest
>> > > > > reset level possible that satisfies the requested functional change.
>> > > > > IOW driver may do more, in fact it should be acceptable for the
>> > > > > driver to always for a full HW reset (unless --live or other
>> > > > > constraint is specified).
>> > > > OK, but some combinations may still not be valid for specific driver
>> > > > even if it tries lowest level possible.
>> > > Can you give an example?
>> > For example take the combination of fw-live-patch and param-init.
>> >
>> > The fw-live-patch needs no re-initialization, while the param-init
>> > requires driver re-initialization.
>> >
>> > So the only way to do that is to the one command after the other, not
>> > really combining.
>> You need to read my responses more carefully. I don't have
>> fw-live-patch in my proposal. The operation is fw-activate,
>> --live is independent and an constraint, not an operation.
>
>
>OK, I probably didn't get the whole picture right.
>
>I am not sure I got it yet, please review if that's the uAPI that you mean
>to:
>
>devlink dev reload [ net-ns-respawn { PID | NAME | ID } ] [ driver-param-init
>] [ fw-activate [ --live] ]
Jakub, why do you prefer to have another extra level-specific option
"live"? I think it is clear to have it as a separate level. The behaviour
of the operation is quite different.
>
>
>Also, I recall that before devlink param was added the devlink reload was
>used for devlink resources.
Yes. That was the primary usecase. That is also why mlxsw does fw reset,
because the fw reset is needed in order to pass resources configuration.
So I don't think that the name should be "driver-param-init" as it is
not specific to params.
>
>I am not sure it is still used for devlink resources as I don't see it in the
>code of devlink reload.
>
>But if it is we probably should add it as another operation.
>
>Jiri, please comment on that.
>
^ permalink raw reply
* RE: [PATCH RFC net-next 2/3] net: phy: Move into subdirectories
From: Madalin Bucur (OSS) @ 2020-08-03 14:11 UTC (permalink / raw)
To: Andrew Lunn, netdev
Cc: Ioana Ciornei, Florian Fainelli, Russell King, Heiner Kallweit
In-Reply-To: <20200727204731.1705418-3-andrew@lunn.ch>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Andrew Lunn
> Sent: 27 July 2020 23:48
> To: netdev <netdev@vger.kernel.org>
> Cc: Ioana Ciornei <ioana.ciornei@nxp.com>; Florian Fainelli
> <f.fainelli@gmail.com>; Russell King <rmk+kernel@armlinux.org.uk>; Heiner
> Kallweit <hkallweit1@gmail.com>; Andrew Lunn <andrew@lunn.ch>
> Subject: [PATCH RFC net-next 2/3] net: phy: Move into subdirectories
>
> Move the PHY drivers into the phy subdirectory
We could keep the PHY drivers in the base drivers/net/phy/ folder, move
only mdio to introduce lesser changes.
> Move the MDIO bus drivers into the mdio subdirectory
>
> Take this opportunity to sort the Kconfig entries based on the text
> that appears in the menu, and the Makefiles.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/phy/Kconfig | 481 +-----------------
> drivers/net/phy/Makefile | 77 +--
> 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 | 0
> 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
> 82 files changed, 559 insertions(+), 544 deletions(-)
> create mode 100644 drivers/net/phy/mdio/Kconfig
> create mode 100644 drivers/net/phy/mdio/Makefile
> rename drivers/net/phy/{ => mdio}/mdio-aspeed.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-bcm-iproc.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-bcm-unimac.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-bitbang.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-cavium.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-cavium.h (100%)
> rename drivers/net/phy/{ => mdio}/mdio-gpio.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-hisi-femac.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-ipq4019.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-ipq8064.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-moxart.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-mscc-miim.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-mux-bcm-iproc.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-mux-gpio.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-mux-meson-g12a.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-mux-mmioreg.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-mux-multiplexer.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-mux.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-mvusb.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-octeon.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-sun4i.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-thunder.c (100%)
> rename drivers/net/phy/{ => mdio}/mdio-xgene.c (100%)
> create mode 100644 drivers/net/phy/phy/Kconfig
> create mode 100644 drivers/net/phy/phy/Makefile
> rename drivers/net/phy/{ => phy}/adin.c (100%)
> rename drivers/net/phy/{ => phy}/amd.c (100%)
> rename drivers/net/phy/{ => phy}/aquantia.h (100%)
> rename drivers/net/phy/{ => phy}/aquantia_hwmon.c (100%)
> rename drivers/net/phy/{ => phy}/aquantia_main.c (100%)
> rename drivers/net/phy/{ => phy}/at803x.c (100%)
> rename drivers/net/phy/{ => phy}/ax88796b.c (100%)
> rename drivers/net/phy/{ => phy}/bcm-cygnus.c (100%)
> rename drivers/net/phy/{ => phy}/bcm-phy-lib.c (100%)
> rename drivers/net/phy/{ => phy}/bcm-phy-lib.h (100%)
> rename drivers/net/phy/{ => phy}/bcm54140.c (100%)
> rename drivers/net/phy/{ => phy}/bcm63xx.c (100%)
> rename drivers/net/phy/{ => phy}/bcm7xxx.c (100%)
> rename drivers/net/phy/{ => phy}/bcm84881.c (100%)
> rename drivers/net/phy/{ => phy}/bcm87xx.c (100%)
> rename drivers/net/phy/{ => phy}/broadcom.c (100%)
> rename drivers/net/phy/{ => phy}/cicada.c (100%)
> rename drivers/net/phy/{ => phy}/cortina.c (100%)
> rename drivers/net/phy/{ => phy}/davicom.c (100%)
> rename drivers/net/phy/{ => phy}/dp83640.c (100%)
> rename drivers/net/phy/{ => phy}/dp83640_reg.h (100%)
> rename drivers/net/phy/{ => phy}/dp83822.c (100%)
> rename drivers/net/phy/{ => phy}/dp83848.c (100%)
> rename drivers/net/phy/{ => phy}/dp83867.c (100%)
> rename drivers/net/phy/{ => phy}/dp83869.c (100%)
> rename drivers/net/phy/{ => phy}/dp83tc811.c (100%)
> rename drivers/net/phy/{ => phy}/et1011c.c (100%)
> rename drivers/net/phy/{ => phy}/icplus.c (100%)
> rename drivers/net/phy/{ => phy}/intel-xway.c (100%)
> rename drivers/net/phy/{ => phy}/lxt.c (100%)
> rename drivers/net/phy/{ => phy}/marvell.c (100%)
> rename drivers/net/phy/{ => phy}/marvell10g.c (100%)
> rename drivers/net/phy/{ => phy}/meson-gxl.c (100%)
> rename drivers/net/phy/{ => phy}/micrel.c (100%)
> rename drivers/net/phy/{ => phy}/microchip.c (100%)
> rename drivers/net/phy/{ => phy}/microchip_t1.c (100%)
> rename drivers/net/phy/{ => phy}/mscc/Makefile (100%)
> rename drivers/net/phy/{ => phy}/mscc/mscc.h (100%)
> rename drivers/net/phy/{ => phy}/mscc/mscc_fc_buffer.h (100%)
> rename drivers/net/phy/{ => phy}/mscc/mscc_mac.h (100%)
> rename drivers/net/phy/{ => phy}/mscc/mscc_macsec.c (100%)
> rename drivers/net/phy/{ => phy}/mscc/mscc_macsec.h (100%)
> rename drivers/net/phy/{ => phy}/mscc/mscc_main.c (100%)
> rename drivers/net/phy/{ => phy}/national.c (100%)
> rename drivers/net/phy/{ => phy}/nxp-tja11xx.c (100%)
> rename drivers/net/phy/{ => phy}/qsemi.c (100%)
> rename drivers/net/phy/{ => phy}/realtek.c (100%)
> rename drivers/net/phy/{ => phy}/rockchip.c (100%)
> rename drivers/net/phy/{ => phy}/smsc.c (100%)
> rename drivers/net/phy/{ => phy}/ste10Xp.c (100%)
> rename drivers/net/phy/{ => phy}/teranetics.c (100%)
> rename drivers/net/phy/{ => phy}/uPD60620.c (100%)
> rename drivers/net/phy/{ => phy}/vitesse.c (100%)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index dd20c2c27c2f..a193236fd65a 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -3,235 +3,7 @@
> # PHY Layer Configuration
> #
>
> -menuconfig MDIO_DEVICE
> - tristate "MDIO bus device drivers"
> - help
> - MDIO devices and driver infrastructure code.
> -
> -if MDIO_DEVICE
> -
> -config MDIO_BUS
> - tristate
> - default m if PHYLIB=m
> - default MDIO_DEVICE
> - help
> - This internal symbol is used for link time dependencies and it
> - reflects whether the mdio_bus/mdio_device code is built as a
> - loadable module or built-in.
> -
> -if MDIO_BUS
> -
> -config MDIO_DEVRES
> - tristate
> -
> -config MDIO_ASPEED
> - tristate "ASPEED MDIO bus controller"
> - depends on ARCH_ASPEED || COMPILE_TEST
> - depends on OF_MDIO && HAS_IOMEM
> - help
> - This module provides a driver for the independent MDIO bus
> - controllers found in the ASPEED AST2600 SoC. This is a driver for
> the
> - third revision of the ASPEED MDIO register interface - the first
> two
> - revisions are the "old" and "new" interfaces found in the AST2400
> and
> - AST2500, embedded in the MAC. For legacy reasons, FTGMAC100 driver
> - continues to drive the embedded MDIO controller for the AST2400
> and
> - AST2500 SoCs, so say N if AST2600 support is not required.
> -
> -config MDIO_BCM_IPROC
> - tristate "Broadcom iProc MDIO bus controller"
> - depends on ARCH_BCM_IPROC || COMPILE_TEST
> - depends on HAS_IOMEM && OF_MDIO
> - default ARCH_BCM_IPROC
> - help
> - This module provides a driver for the MDIO busses found in the
> - Broadcom iProc SoC's.
> -
> -config MDIO_BCM_UNIMAC
> - tristate "Broadcom UniMAC MDIO bus controller"
> - depends on HAS_IOMEM
> - help
> - This module provides a driver for the Broadcom UniMAC MDIO busses.
> - This hardware can be found in the Broadcom GENET Ethernet MAC
> - controllers as well as some Broadcom Ethernet switches such as the
> - Starfighter 2 switches.
> -
> -config MDIO_BITBANG
> - tristate "Bitbanged MDIO buses"
> - help
> - This module implements the MDIO bus protocol in software,
> - for use by low level drivers that export the ability to
> - drive the relevant pins.
> -
> - If in doubt, say N.
> -
> -config MDIO_BUS_MUX
> - tristate
> - depends on OF_MDIO
> - help
> - This module provides a driver framework for MDIO bus
> - multiplexers which connect one of several child MDIO busses
> - to a parent bus. Switching between child busses is done by
> - device specific drivers.
> -
> -config MDIO_BUS_MUX_BCM_IPROC
> - tristate "Broadcom iProc based MDIO bus multiplexers"
> - depends on OF && OF_MDIO && (ARCH_BCM_IPROC || COMPILE_TEST)
> - select MDIO_BUS_MUX
> - default ARCH_BCM_IPROC
> - help
> - This module provides a driver for MDIO bus multiplexers found in
> - iProc based Broadcom SoCs. This multiplexer connects one of
> several
> - child MDIO bus to a parent bus. Buses could be internal as well as
> - external and selection logic lies inside the same multiplexer.
> -
> -config MDIO_BUS_MUX_GPIO
> - tristate "GPIO controlled MDIO bus multiplexers"
> - depends on OF_GPIO && OF_MDIO
> - select MDIO_BUS_MUX
> - help
> - This module provides a driver for MDIO bus multiplexers that
> - are controlled via GPIO lines. The multiplexer connects one of
> - several child MDIO busses to a parent bus. Child bus
> - selection is under the control of GPIO lines.
> -
> -config MDIO_BUS_MUX_MESON_G12A
> - tristate "Amlogic G12a based MDIO bus multiplexer"
> - depends on ARCH_MESON || COMPILE_TEST
> - depends on OF_MDIO && HAS_IOMEM && COMMON_CLK
> - select MDIO_BUS_MUX
> - default m if ARCH_MESON
> - help
> - This module provides a driver for the MDIO multiplexer/glue of
> - the amlogic g12a SoC. The multiplexers connects either the
> external
> - or the internal MDIO bus to the parent bus.
> -
> -config MDIO_BUS_MUX_MMIOREG
> - tristate "MMIO device-controlled MDIO bus multiplexers"
> - depends on OF_MDIO && HAS_IOMEM
> - select MDIO_BUS_MUX
> - help
> - This module provides a driver for MDIO bus multiplexers that
> - are controlled via a simple memory-mapped device, like an FPGA.
> - The multiplexer connects one of several child MDIO busses to a
> - parent bus. Child bus selection is under the control of one of
> - the FPGA's registers.
> -
> - Currently, only 8/16/32 bits registers are supported.
> -
> -config MDIO_BUS_MUX_MULTIPLEXER
> - tristate "MDIO bus multiplexer using kernel multiplexer subsystem"
> - depends on OF_MDIO
> - select MULTIPLEXER
> - select MDIO_BUS_MUX
> - help
> - This module provides a driver for MDIO bus multiplexer
> - that is controlled via the kernel multiplexer subsystem. The
> - bus multiplexer connects one of several child MDIO busses to
> - a parent bus. Child bus selection is under the control of
> - the kernel multiplexer subsystem.
> -
> -config MDIO_CAVIUM
> - tristate
> -
> -config MDIO_GPIO
> - tristate "GPIO lib-based bitbanged MDIO buses"
> - depends on MDIO_BITBANG
> - depends on GPIOLIB || COMPILE_TEST
> - help
> - Supports GPIO lib-based MDIO busses.
> -
> - To compile this driver as a module, choose M here: the module
> - will be called mdio-gpio.
> -
> -config MDIO_HISI_FEMAC
> - tristate "Hisilicon FEMAC MDIO bus controller"
> - depends on HAS_IOMEM && OF_MDIO
> - help
> - This module provides a driver for the MDIO busses found in the
> - Hisilicon SoC that have an Fast Ethernet MAC.
> -
> -config MDIO_I2C
> - tristate
> - depends on I2C
> - help
> - Support I2C based PHYs. This provides a MDIO bus bridged
> - to I2C to allow PHYs connected in I2C mode to be accessed
> - using the existing infrastructure.
> -
> - This is library mode.
> -
> -config MDIO_IPQ4019
> - tristate "Qualcomm IPQ4019 MDIO interface support"
> - depends on HAS_IOMEM && OF_MDIO
> - help
> - This driver supports the MDIO interface found in Qualcomm
> - IPQ40xx series Soc-s.
> -
> -config MDIO_IPQ8064
> - tristate "Qualcomm IPQ8064 MDIO interface support"
> - depends on HAS_IOMEM && OF_MDIO
> - depends on MFD_SYSCON
> - help
> - This driver supports the MDIO interface found in the network
> - interface units of the IPQ8064 SoC
> -
> -config MDIO_MOXART
> - tristate "MOXA ART MDIO interface support"
> - depends on ARCH_MOXART || COMPILE_TEST
> - help
> - This driver supports the MDIO interface found in the network
> - interface units of the MOXA ART SoC
> -
> -config MDIO_MSCC_MIIM
> - tristate "Microsemi MIIM interface support"
> - depends on HAS_IOMEM
> - select MDIO_DEVRES
> - help
> - This driver supports the MIIM (MDIO) interface found in the
> network
> - switches of the Microsemi SoCs; it is recommended to switch on
> - CONFIG_HIGH_RES_TIMERS
> -
> -config MDIO_MVUSB
> - tristate "Marvell USB to MDIO Adapter"
> - depends on USB
> - help
> - A USB to MDIO converter present on development boards for
> - Marvell's Link Street family of Ethernet switches.
> -
> -config MDIO_OCTEON
> - tristate "Octeon and some ThunderX SOCs MDIO buses"
> - depends on (64BIT && OF_MDIO) || COMPILE_TEST
> - depends on HAS_IOMEM
> - select MDIO_CAVIUM
> - help
> - This module provides a driver for the Octeon and ThunderX MDIO
> - buses. It is required by the Octeon and ThunderX ethernet device
> - drivers on some systems.
> -
> -config MDIO_SUN4I
> - tristate "Allwinner sun4i MDIO interface support"
> - depends on ARCH_SUNXI || COMPILE_TEST
> - help
> - This driver supports the MDIO interface found in the network
> - interface units of the Allwinner SoC that have an EMAC (A10,
> - A12, A10s, etc.)
> -
> -config MDIO_THUNDER
> - tristate "ThunderX SOCs MDIO buses"
> - depends on 64BIT
> - depends on PCI
> - select MDIO_CAVIUM
> - help
> - This driver supports the MDIO interfaces found on Cavium
> - ThunderX SoCs when the MDIO bus device appears as a PCI
> - device.
> -
> -config MDIO_XGENE
> - tristate "APM X-Gene SoC MDIO bus controller"
> - depends on ARCH_XGENE || COMPILE_TEST
> - help
> - This module provides a driver for the MDIO busses found in the
> - APM X-Gene SoC's.
> +source "drivers/net/phy/mdio/Kconfig"
>
> config MDIO_XPCS
> tristate "Synopsys DesignWare XPCS controller"
> @@ -239,9 +11,6 @@ config MDIO_XPCS
> This module provides helper functions for Synopsys DesignWare XPCS
> controllers.
>
> -endif
> -endif
> -
> config PHYLINK
> tristate
> depends on NETDEVICES
> @@ -292,132 +61,6 @@ config SFP
> depends on HWMON || HWMON=n
> select MDIO_I2C
>
> -config ADIN_PHY
> - tristate "Analog Devices Industrial Ethernet PHYs"
> - help
> - Adds support for the Analog Devices Industrial Ethernet PHYs.
> - Currently supports the:
> - - ADIN1200 - Robust,Industrial, Low Power 10/100 Ethernet PHY
> - - ADIN1300 - Robust,Industrial, Low Latency 10/100/1000 Gigabit
> - Ethernet PHY
> -
> -config AMD_PHY
> - tristate "AMD PHYs"
> - help
> - Currently supports the am79c874
> -
> -config AQUANTIA_PHY
> - tristate "Aquantia PHYs"
> - help
> - Currently supports the Aquantia AQ1202, AQ2104, AQR105, AQR405
> -
> -config AX88796B_PHY
> - tristate "Asix PHYs"
> - help
> - Currently supports the Asix Electronics PHY found in the X-Surf
> 100
> - AX88796B package.
> -
> -config BCM63XX_PHY
> - tristate "Broadcom 63xx SOCs internal PHY"
> - depends on BCM63XX || COMPILE_TEST
> - select BCM_NET_PHYLIB
> - help
> - Currently supports the 6348 and 6358 PHYs.
> -
> -config BCM7XXX_PHY
> - tristate "Broadcom 7xxx SOCs internal PHYs"
> - select BCM_NET_PHYLIB
> - help
> - Currently supports the BCM7366, BCM7439, BCM7445, and
> - 40nm and 65nm generation of BCM7xxx Set Top Box SoCs.
> -
> -config BCM87XX_PHY
> - tristate "Broadcom BCM8706 and BCM8727 PHYs"
> - help
> - Currently supports the BCM8706 and BCM8727 10G Ethernet PHYs.
> -
> -config BCM_CYGNUS_PHY
> - tristate "Broadcom Cygnus/Omega SoC internal PHY"
> - depends on ARCH_BCM_IPROC || COMPILE_TEST
> - depends on MDIO_BCM_IPROC
> - select BCM_NET_PHYLIB
> - help
> - This PHY driver is for the 1G internal PHYs of the Broadcom
> - Cygnus and Omega Family SoC.
> -
> - Currently supports internal PHY's used in the BCM11300,
> - BCM11320, BCM11350, BCM11360, BCM58300, BCM58302,
> - BCM58303 & BCM58305 Broadcom Cygnus SoCs.
> -
> -config BCM_NET_PHYLIB
> - tristate
> -
> -config BROADCOM_PHY
> - tristate "Broadcom PHYs"
> - select BCM_NET_PHYLIB
> - help
> - Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S,
> BCM5464,
> - BCM5481, BCM54810 and BCM5482 PHYs.
> -
> -config BCM54140_PHY
> - tristate "Broadcom BCM54140 PHY"
> - depends on PHYLIB
> - depends on HWMON || HWMON=n
> - select BCM_NET_PHYLIB
> - help
> - Support the Broadcom BCM54140 Quad SGMII/QSGMII PHY.
> -
> - This driver also supports the hardware monitoring of this PHY and
> - exposes voltage and temperature sensors.
> -
> -config BCM84881_PHY
> - tristate "Broadcom BCM84881 PHY"
> - depends on PHYLIB
> - help
> - Support the Broadcom BCM84881 PHY.
> -
> -config CICADA_PHY
> - tristate "Cicada PHYs"
> - help
> - Currently supports the cis8204
> -
> -config CORTINA_PHY
> - tristate "Cortina EDC CDR 10G Ethernet PHY"
> - help
> - Currently supports the CS4340 phy.
> -
> -config DAVICOM_PHY
> - tristate "Davicom PHYs"
> - help
> - Currently supports dm9161e and dm9131
> -
> -config DP83822_PHY
> - tristate "Texas Instruments DP83822/825/826 PHYs"
> - help
> - Supports the DP83822, DP83825I, DP83825CM, DP83825CS, DP83825S,
> - DP83826C and DP83826NC PHYs.
> -
> -config DP83TC811_PHY
> - tristate "Texas Instruments DP83TC811 PHY"
> - help
> - Supports the DP83TC811 PHY.
> -
> -config DP83848_PHY
> - tristate "Texas Instruments DP83848 PHY"
> - help
> - Supports the DP83848 PHY.
> -
> -config DP83867_PHY
> - tristate "Texas Instruments DP83867 Gigabit PHY"
> - help
> - Currently supports the DP83867 PHY.
> -
> -config DP83869_PHY
> - tristate "Texas Instruments DP83869 Gigabit PHY"
> - help
> - Currently supports the DP83869 PHY. This PHY supports copper and
> - fiber connections.
> -
> config FIXED_PHY
> tristate "MDIO Bus/PHY emulation with fixed speed/link PHYs"
> depends on PHYLIB
> @@ -428,123 +71,17 @@ config FIXED_PHY
>
> Currently tested with mpc866ads and mpc8349e-mitx.
>
> -config ICPLUS_PHY
> - tristate "ICPlus PHYs"
> - help
> - Currently supports the IP175C and IP1001 PHYs.
> -
> -config INTEL_XWAY_PHY
> - tristate "Intel XWAY PHYs"
> - help
> - Supports the Intel XWAY (former Lantiq) 11G and 22E PHYs.
> - These PHYs are marked as standalone chips under the names
> - PEF 7061, PEF 7071 and PEF 7072 or integrated into the Intel
> - SoCs xRX200, xRX300, xRX330, xRX350 and xRX550.
> -
> -config LSI_ET1011C_PHY
> - tristate "LSI ET1011C PHY"
> - help
> - Supports the LSI ET1011C PHY.
> -
> -config LXT_PHY
> - tristate "Intel LXT PHYs"
> - help
> - Currently supports the lxt970, lxt971
> -
> -config MARVELL_PHY
> - tristate "Marvell PHYs"
> - help
> - Currently has a driver for the 88E1011S
> -
> -config MARVELL_10G_PHY
> - tristate "Marvell Alaska 10Gbit PHYs"
> - help
> - Support for the Marvell Alaska MV88X3310 and compatible PHYs.
> -
> -config MESON_GXL_PHY
> - tristate "Amlogic Meson GXL Internal PHY"
> - depends on ARCH_MESON || COMPILE_TEST
> - help
> - Currently has a driver for the Amlogic Meson GXL Internal PHY
> -
> -config MICREL_PHY
> - tristate "Micrel PHYs"
> - help
> - Supports the KSZ9021, VSC8201, KS8001 PHYs.
> -
> -config MICROCHIP_PHY
> - tristate "Microchip PHYs"
> - help
> - Supports the LAN88XX PHYs.
> -
> -config MICROCHIP_T1_PHY
> - tristate "Microchip T1 PHYs"
> - help
> - Supports the LAN87XX PHYs.
> -
> -config MICROSEMI_PHY
> - tristate "Microsemi PHYs"
> - depends on MACSEC || MACSEC=n
> - select CRYPTO_LIB_AES if MACSEC
> - help
> - Currently supports VSC8514, VSC8530, VSC8531, VSC8540 and VSC8541
> PHYs
> -
> -config NATIONAL_PHY
> - tristate "National Semiconductor PHYs"
> - help
> - Currently supports the DP83865 PHY.
> -
> -config NXP_TJA11XX_PHY
> - tristate "NXP TJA11xx PHYs support"
> - depends on HWMON
> - help
> - Currently supports the NXP TJA1100 and TJA1101 PHY.
> -
> -config AT803X_PHY
> - tristate "Qualcomm Atheros AR803X PHYs"
> - depends on REGULATOR
> - help
> - Currently supports the AR8030, AR8031, AR8033 and AR8035 model
> -
> -config QSEMI_PHY
> - tristate "Quality Semiconductor PHYs"
> - help
> - Currently supports the qs6612
> -
> -config REALTEK_PHY
> - tristate "Realtek PHYs"
> - help
> - Supports the Realtek 821x PHY.
> -
> -config RENESAS_PHY
> - tristate "Driver for Renesas PHYs"
> - help
> - Supports the Renesas PHYs uPD60620 and uPD60620A.
> -
> -config ROCKCHIP_PHY
> - tristate "Driver for Rockchip Ethernet PHYs"
> - help
> - Currently supports the integrated Ethernet PHY.
> -
> -config SMSC_PHY
> - tristate "SMSC PHYs"
> - help
> - Currently supports the LAN83C185, LAN8187 and LAN8700 PHYs
> -
> -config STE10XP
> - tristate "STMicroelectronics STe10Xp PHYs"
> +config MDIO_I2C
> + tristate
> + depends on I2C
> help
> - This is the driver for the STe100p and STe101p PHYs.
> + Support I2C based PHYs. This provides a MDIO bus bridged
> + to I2C to allow PHYs connected in I2C mode to be accessed
> + using the existing infrastructure.
>
> -config TERANETICS_PHY
> - tristate "Teranetics PHYs"
> - help
> - Currently supports the Teranetics TN2020
> + This is library mode.
>
> -config VITESSE_PHY
> - tristate "Vitesse PHYs"
> - help
> - Currently supports the vsc8244
> +source "drivers/net/phy/phy/Kconfig"
>
> config XILINX_GMII2RGMII
> tristate "Xilinx GMII2RGMII converter driver"
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index d84bab489a53..6bdf04478d34 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -1,6 +1,8 @@
> # SPDX-License-Identifier: GPL-2.0
> # Makefile for Linux PHY drivers and MDIO bus drivers
>
> +obj-y += phy/ mdio/
> +
> libphy-y := phy.o phy-c45.o phy-core.o phy_device.o \
> linkmode.o
> mdio-bus-y += mdio_bus.o mdio_device.o
> @@ -23,30 +25,8 @@ libphy-$(CONFIG_LED_TRIGGER_PHY) +=
> phy_led_triggers.o
>
> obj-$(CONFIG_PHYLINK) += phylink.o
> obj-$(CONFIG_PHYLIB) += libphy.o
> +obj-$(CONFIG_FIXED_PHY) += fixed_phy.o
>
> -obj-$(CONFIG_MDIO_ASPEED) += mdio-aspeed.o
> -obj-$(CONFIG_MDIO_BCM_IPROC) += mdio-bcm-iproc.o
> -obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
> -obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
> -obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
> -obj-$(CONFIG_MDIO_BUS_MUX_BCM_IPROC) += mdio-mux-bcm-iproc.o
> -obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
> -obj-$(CONFIG_MDIO_BUS_MUX_MESON_G12A) += mdio-mux-meson-g12a.o
> -obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
> -obj-$(CONFIG_MDIO_BUS_MUX_MULTIPLEXER) += mdio-mux-multiplexer.o
> -obj-$(CONFIG_MDIO_CAVIUM) += mdio-cavium.o
> -obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
> -obj-$(CONFIG_MDIO_HISI_FEMAC) += mdio-hisi-femac.o
> -obj-$(CONFIG_MDIO_I2C) += mdio-i2c.o
> -obj-$(CONFIG_MDIO_IPQ4019) += mdio-ipq4019.o
> -obj-$(CONFIG_MDIO_IPQ8064) += mdio-ipq8064.o
> -obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
> -obj-$(CONFIG_MDIO_MSCC_MIIM) += mdio-mscc-miim.o
> -obj-$(CONFIG_MDIO_MVUSB) += mdio-mvusb.o
> -obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
> -obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
> -obj-$(CONFIG_MDIO_THUNDER) += mdio-thunder.o
> -obj-$(CONFIG_MDIO_XGENE) += mdio-xgene.o
> obj-$(CONFIG_MDIO_XPCS) += mdio-xpcs.o
>
> obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) += mii_timestamper.o
> @@ -54,54 +34,7 @@ obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) +=
> mii_timestamper.o
> obj-$(CONFIG_SFP) += sfp.o
> sfp-obj-$(CONFIG_SFP) += sfp-bus.o
> obj-y += $(sfp-obj-y) $(sfp-obj-m)
> +obj-$(CONFIG_MDIO_I2C) += mdio-i2c.o
>
> -obj-$(CONFIG_ADIN_PHY) += adin.o
> -obj-$(CONFIG_AMD_PHY) += amd.o
> -aquantia-objs += aquantia_main.o
> -ifdef CONFIG_HWMON
> -aquantia-objs += aquantia_hwmon.o
> -endif
> -obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
> -obj-$(CONFIG_AX88796B_PHY) += ax88796b.o
> -obj-$(CONFIG_AT803X_PHY) += at803x.o
> -obj-$(CONFIG_BCM63XX_PHY) += bcm63xx.o
> -obj-$(CONFIG_BCM7XXX_PHY) += bcm7xxx.o
> -obj-$(CONFIG_BCM87XX_PHY) += bcm87xx.o
> -obj-$(CONFIG_BCM_CYGNUS_PHY) += bcm-cygnus.o
> -obj-$(CONFIG_BCM_NET_PHYLIB) += bcm-phy-lib.o
> -obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
> -obj-$(CONFIG_BCM54140_PHY) += bcm54140.o
> -obj-$(CONFIG_BCM84881_PHY) += bcm84881.o
> -obj-$(CONFIG_CICADA_PHY) += cicada.o
> -obj-$(CONFIG_CORTINA_PHY) += cortina.o
> -obj-$(CONFIG_DAVICOM_PHY) += davicom.o
> -obj-$(CONFIG_DP83640_PHY) += dp83640.o
> -obj-$(CONFIG_DP83822_PHY) += dp83822.o
> -obj-$(CONFIG_DP83TC811_PHY) += dp83tc811.o
> -obj-$(CONFIG_DP83848_PHY) += dp83848.o
> -obj-$(CONFIG_DP83867_PHY) += dp83867.o
> -obj-$(CONFIG_DP83869_PHY) += dp83869.o
> -obj-$(CONFIG_FIXED_PHY) += fixed_phy.o
> -obj-$(CONFIG_ICPLUS_PHY) += icplus.o
> -obj-$(CONFIG_INTEL_XWAY_PHY) += intel-xway.o
> -obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
> -obj-$(CONFIG_LXT_PHY) += lxt.o
> -obj-$(CONFIG_MARVELL_PHY) += marvell.o
> -obj-$(CONFIG_MARVELL_10G_PHY) += marvell10g.o
> -obj-$(CONFIG_MESON_GXL_PHY) += meson-gxl.o
> obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
> -obj-$(CONFIG_MICREL_PHY) += micrel.o
> -obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
> -obj-$(CONFIG_MICROCHIP_T1_PHY) += microchip_t1.o
> -obj-$(CONFIG_MICROSEMI_PHY) += mscc/
> -obj-$(CONFIG_NATIONAL_PHY) += national.o
> -obj-$(CONFIG_NXP_TJA11XX_PHY) += nxp-tja11xx.o
> -obj-$(CONFIG_QSEMI_PHY) += qsemi.o
> -obj-$(CONFIG_REALTEK_PHY) += realtek.o
> -obj-$(CONFIG_RENESAS_PHY) += uPD60620.o
> -obj-$(CONFIG_ROCKCHIP_PHY) += rockchip.o
> -obj-$(CONFIG_SMSC_PHY) += smsc.o
> -obj-$(CONFIG_STE10XP) += ste10Xp.o
> -obj-$(CONFIG_TERANETICS_PHY) += teranetics.o
> -obj-$(CONFIG_VITESSE_PHY) += vitesse.o
> -obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
> +
> diff --git a/drivers/net/phy/mdio/Kconfig b/drivers/net/phy/mdio/Kconfig
> new file mode 100644
> index 000000000000..f5ea07b84d65
> --- /dev/null
> +++ b/drivers/net/phy/mdio/Kconfig
> @@ -0,0 +1,226 @@
> +menuconfig MDIO_DEVICE
> + tristate "MDIO bus device drivers"
> + help
> + MDIO devices and driver infrastructure code.
> +
> +if MDIO_DEVICE
> +
> +config MDIO_BUS
> + tristate
> + default m if PHYLIB=m
> + default MDIO_DEVICE
> + help
> + This internal symbol is used for link time dependencies and it
> + reflects whether the mdio_bus/mdio_device code is built as a
> + loadable module or built-in.
> +
> +if MDIO_BUS
> +
> +config MDIO_DEVRES
> + tristate
> +
> +comment "MDIO Multiplexor drivers"
> +
> +config MDIO_BUS_MUX
> + tristate
> + depends on OF_MDIO
> + help
> + This module provides a driver framework for MDIO bus
> + multiplexers which connect one of several child MDIO busses
> + to a parent bus. Switching between child busses is done by
> + device specific drivers.
> +
> +config MDIO_BUS_MUX_MESON_G12A
> + tristate "Amlogic G12a based MDIO bus multiplexer"
> + depends on ARCH_MESON || COMPILE_TEST
> + depends on OF_MDIO && HAS_IOMEM && COMMON_CLK
> + select MDIO_BUS_MUX
> + default m if ARCH_MESON
> + help
> + This module provides a driver for the MDIO multiplexer/glue of
> + the amlogic g12a SoC. The multiplexers connects either the
> external
> + or the internal MDIO bus to the parent bus.
> +
> +config MDIO_BUS_MUX_BCM_IPROC
> + tristate "Broadcom iProc based MDIO bus multiplexers"
> + depends on OF && OF_MDIO && (ARCH_BCM_IPROC || COMPILE_TEST)
> + select MDIO_BUS_MUX
> + default ARCH_BCM_IPROC
> + help
> + This module provides a driver for MDIO bus multiplexers found in
> + iProc based Broadcom SoCs. This multiplexer connects one of
> several
> + child MDIO bus to a parent bus. Buses could be internal as well as
> + external and selection logic lies inside the same multiplexer.
> +
> +config MDIO_BUS_MUX_GPIO
> + tristate "GPIO controlled MDIO bus multiplexers"
> + depends on OF_GPIO && OF_MDIO
> + select MDIO_BUS_MUX
> + help
> + This module provides a driver for MDIO bus multiplexers that
> + are controlled via GPIO lines. The multiplexer connects one of
> + several child MDIO busses to a parent bus. Child bus
> + selection is under the control of GPIO lines.
> +
> +config MDIO_BUS_MUX_MULTIPLEXER
> + tristate "MDIO bus multiplexer using kernel multiplexer subsystem"
> + depends on OF_MDIO
> + select MULTIPLEXER
> + select MDIO_BUS_MUX
> + help
> + This module provides a driver for MDIO bus multiplexer
> + that is controlled via the kernel multiplexer subsystem. The
> + bus multiplexer connects one of several child MDIO busses to
> + a parent bus. Child bus selection is under the control of
> + the kernel multiplexer subsystem.
> +
> +config MDIO_BUS_MUX_MMIOREG
> + tristate "MMIO device-controlled MDIO bus multiplexers"
> + depends on OF_MDIO && HAS_IOMEM
> + select MDIO_BUS_MUX
> + help
> + This module provides a driver for MDIO bus multiplexers that
> + are controlled via a simple memory-mapped device, like an FPGA.
> + The multiplexer connects one of several child MDIO busses to a
> + parent bus. Child bus selection is under the control of one of
> + the FPGA's registers.
> +
> + Currently, only 8/16/32 bits registers are supported.
> +
> +comment "MDIO Bus drivers"
> +
> +config MDIO_SUN4I
> + tristate "Allwinner sun4i MDIO interface support"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + help
> + This driver supports the MDIO interface found in the network
> + interface units of the Allwinner SoC that have an EMAC (A10,
> + A12, A10s, etc.)
> +
> +config MDIO_XGENE
> + tristate "APM X-Gene SoC MDIO bus controller"
> + depends on ARCH_XGENE || COMPILE_TEST
> + help
> + This module provides a driver for the MDIO busses found in the
> + APM X-Gene SoC's.
> +
> +config MDIO_ASPEED
> + tristate "ASPEED MDIO bus controller"
> + depends on ARCH_ASPEED || COMPILE_TEST
> + depends on OF_MDIO && HAS_IOMEM
> + help
> + This module provides a driver for the independent MDIO bus
> + controllers found in the ASPEED AST2600 SoC. This is a driver for
> the
> + third revision of the ASPEED MDIO register interface - the first
> two
> + revisions are the "old" and "new" interfaces found in the AST2400
> and
> + AST2500, embedded in the MAC. For legacy reasons, FTGMAC100 driver
> + continues to drive the embedded MDIO controller for the AST2400
> and
> + AST2500 SoCs, so say N if AST2600 support is not required.
> +
> +config MDIO_BITBANG
> + tristate "Bitbanged MDIO buses"
> + help
> + This module implements the MDIO bus protocol in software,
> + for use by low level drivers that export the ability to
> + drive the relevant pins.
> +
> + If in doubt, say N.
> +
> +config MDIO_BCM_IPROC
> + tristate "Broadcom iProc MDIO bus controller"
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + depends on HAS_IOMEM && OF_MDIO
> + default ARCH_BCM_IPROC
> + help
> + This module provides a driver for the MDIO busses found in the
> + Broadcom iProc SoC's.
> +
> +config MDIO_BCM_UNIMAC
> + tristate "Broadcom UniMAC MDIO bus controller"
> + depends on HAS_IOMEM
> + help
> + This module provides a driver for the Broadcom UniMAC MDIO busses.
> + This hardware can be found in the Broadcom GENET Ethernet MAC
> + controllers as well as some Broadcom Ethernet switches such as the
> + Starfighter 2 switches.
> +
> +config MDIO_CAVIUM
> + tristate
> +
> +config MDIO_GPIO
> + tristate "GPIO lib-based bitbanged MDIO buses"
> + depends on MDIO_BITBANG
> + depends on GPIOLIB || COMPILE_TEST
> + help
> + Supports GPIO lib-based MDIO busses.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called mdio-gpio.
> +
> +config MDIO_HISI_FEMAC
> + tristate "Hisilicon FEMAC MDIO bus controller"
> + depends on HAS_IOMEM && OF_MDIO
> + help
> + This module provides a driver for the MDIO busses found in the
> + Hisilicon SoC that have an Fast Ethernet MAC.
> +
> +config MDIO_MVUSB
> + tristate "Marvell USB to MDIO Adapter"
> + depends on USB
> + help
> + A USB to MDIO converter present on development boards for
> + Marvell's Link Street family of Ethernet switches.
> +
> +config MDIO_MSCC_MIIM
> + tristate "Microsemi MIIM interface support"
> + depends on HAS_IOMEM
> + select MDIO_DEVRES
> + help
> + This driver supports the MIIM (MDIO) interface found in the
> network
> + switches of the Microsemi SoCs; it is recommended to switch on
> + CONFIG_HIGH_RES_TIMERS
> +
> +config MDIO_MOXART
> + tristate "MOXA ART MDIO interface support"
> + depends on ARCH_MOXART || COMPILE_TEST
> + help
> + This driver supports the MDIO interface found in the network
> + interface units of the MOXA ART SoC
> +
> +config MDIO_OCTEON
> + tristate "Octeon and some ThunderX SOCs MDIO buses"
> + depends on (64BIT && OF_MDIO) || COMPILE_TEST
> + depends on HAS_IOMEM
> + select MDIO_CAVIUM
> + help
> + This module provides a driver for the Octeon and ThunderX MDIO
> + buses. It is required by the Octeon and ThunderX ethernet device
> + drivers on some systems.
> +
> +config MDIO_IPQ4019
> + tristate "Qualcomm IPQ4019 MDIO interface support"
> + depends on HAS_IOMEM && OF_MDIO
> + help
> + This driver supports the MDIO interface found in Qualcomm
> + IPQ40xx series Soc-s.
> +
> +config MDIO_IPQ8064
> + tristate "Qualcomm IPQ8064 MDIO interface support"
> + depends on HAS_IOMEM && OF_MDIO
> + depends on MFD_SYSCON
> + help
> + This driver supports the MDIO interface found in the network
> + interface units of the IPQ8064 SoC
> +
> +config MDIO_THUNDER
> + tristate "ThunderX SOCs MDIO buses"
> + depends on 64BIT
> + depends on PCI
> + select MDIO_CAVIUM
> + help
> + This driver supports the MDIO interfaces found on Cavium
> + ThunderX SoCs when the MDIO bus device appears as a PCI
> + device.
> +
> +endif
> +endif
> diff --git a/drivers/net/phy/mdio/Makefile b/drivers/net/phy/mdio/Makefile
> new file mode 100644
> index 000000000000..9f52aca3bc60
> --- /dev/null
> +++ b/drivers/net/phy/mdio/Makefile
> @@ -0,0 +1,26 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Makefile for Linux MDIO bus drivers
> +
> +obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
> +obj-$(CONFIG_MDIO_BUS_MUX_BCM_IPROC) += mdio-mux-bcm-iproc.o
> +obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
> +obj-$(CONFIG_MDIO_BUS_MUX_MESON_G12A) += mdio-mux-meson-g12a.o
> +obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
> +obj-$(CONFIG_MDIO_BUS_MUX_MULTIPLEXER) += mdio-mux-multiplexer.o
> +
> +obj-$(CONFIG_MDIO_ASPEED) += mdio-aspeed.o
> +obj-$(CONFIG_MDIO_BCM_IPROC) += mdio-bcm-iproc.o
> +obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
> +obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
> +obj-$(CONFIG_MDIO_CAVIUM) += mdio-cavium.o
> +obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
> +obj-$(CONFIG_MDIO_HISI_FEMAC) += mdio-hisi-femac.o
> +obj-$(CONFIG_MDIO_IPQ4019) += mdio-ipq4019.o
> +obj-$(CONFIG_MDIO_IPQ8064) += mdio-ipq8064.o
> +obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
> +obj-$(CONFIG_MDIO_MSCC_MIIM) += mdio-mscc-miim.o
> +obj-$(CONFIG_MDIO_MVUSB) += mdio-mvusb.o
> +obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
> +obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
> +obj-$(CONFIG_MDIO_THUNDER) += mdio-thunder.o
> +obj-$(CONFIG_MDIO_XGENE) += mdio-xgene.o
> diff --git a/drivers/net/phy/mdio-aspeed.c b/drivers/net/phy/mdio/mdio-
> aspeed.c
> similarity index 100%
> rename from drivers/net/phy/mdio-aspeed.c
> rename to drivers/net/phy/mdio/mdio-aspeed.c
> diff --git a/drivers/net/phy/mdio-bcm-iproc.c b/drivers/net/phy/mdio/mdio-
> bcm-iproc.c
> similarity index 100%
> rename from drivers/net/phy/mdio-bcm-iproc.c
> rename to drivers/net/phy/mdio/mdio-bcm-iproc.c
> diff --git a/drivers/net/phy/mdio-bcm-unimac.c
> b/drivers/net/phy/mdio/mdio-bcm-unimac.c
> similarity index 100%
> rename from drivers/net/phy/mdio-bcm-unimac.c
> rename to drivers/net/phy/mdio/mdio-bcm-unimac.c
> diff --git a/drivers/net/phy/mdio-bitbang.c b/drivers/net/phy/mdio/mdio-
> bitbang.c
> similarity index 100%
> rename from drivers/net/phy/mdio-bitbang.c
> rename to drivers/net/phy/mdio/mdio-bitbang.c
> diff --git a/drivers/net/phy/mdio-cavium.c b/drivers/net/phy/mdio/mdio-
> cavium.c
> similarity index 100%
> rename from drivers/net/phy/mdio-cavium.c
> rename to drivers/net/phy/mdio/mdio-cavium.c
> diff --git a/drivers/net/phy/mdio-cavium.h b/drivers/net/phy/mdio/mdio-
> cavium.h
> similarity index 100%
> rename from drivers/net/phy/mdio-cavium.h
> rename to drivers/net/phy/mdio/mdio-cavium.h
> diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio/mdio-
> gpio.c
> similarity index 100%
> rename from drivers/net/phy/mdio-gpio.c
> rename to drivers/net/phy/mdio/mdio-gpio.c
> diff --git a/drivers/net/phy/mdio-hisi-femac.c
> b/drivers/net/phy/mdio/mdio-hisi-femac.c
> similarity index 100%
> rename from drivers/net/phy/mdio-hisi-femac.c
> rename to drivers/net/phy/mdio/mdio-hisi-femac.c
> diff --git a/drivers/net/phy/mdio-ipq4019.c b/drivers/net/phy/mdio/mdio-
> ipq4019.c
> similarity index 100%
> rename from drivers/net/phy/mdio-ipq4019.c
> rename to drivers/net/phy/mdio/mdio-ipq4019.c
> diff --git a/drivers/net/phy/mdio-ipq8064.c b/drivers/net/phy/mdio/mdio-
> ipq8064.c
> similarity index 100%
> rename from drivers/net/phy/mdio-ipq8064.c
> rename to drivers/net/phy/mdio/mdio-ipq8064.c
> diff --git a/drivers/net/phy/mdio-moxart.c b/drivers/net/phy/mdio/mdio-
> moxart.c
> similarity index 100%
> rename from drivers/net/phy/mdio-moxart.c
> rename to drivers/net/phy/mdio/mdio-moxart.c
> diff --git a/drivers/net/phy/mdio-mscc-miim.c b/drivers/net/phy/mdio/mdio-
> mscc-miim.c
> similarity index 100%
> rename from drivers/net/phy/mdio-mscc-miim.c
> rename to drivers/net/phy/mdio/mdio-mscc-miim.c
> diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c
> b/drivers/net/phy/mdio/mdio-mux-bcm-iproc.c
> similarity index 100%
> rename from drivers/net/phy/mdio-mux-bcm-iproc.c
> rename to drivers/net/phy/mdio/mdio-mux-bcm-iproc.c
> diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio/mdio-
> mux-gpio.c
> similarity index 100%
> rename from drivers/net/phy/mdio-mux-gpio.c
> rename to drivers/net/phy/mdio/mdio-mux-gpio.c
> diff --git a/drivers/net/phy/mdio-mux-meson-g12a.c
> b/drivers/net/phy/mdio/mdio-mux-meson-g12a.c
> similarity index 100%
> rename from drivers/net/phy/mdio-mux-meson-g12a.c
> rename to drivers/net/phy/mdio/mdio-mux-meson-g12a.c
> diff --git a/drivers/net/phy/mdio-mux-mmioreg.c
> b/drivers/net/phy/mdio/mdio-mux-mmioreg.c
> similarity index 100%
> rename from drivers/net/phy/mdio-mux-mmioreg.c
> rename to drivers/net/phy/mdio/mdio-mux-mmioreg.c
> diff --git a/drivers/net/phy/mdio-mux-multiplexer.c
> b/drivers/net/phy/mdio/mdio-mux-multiplexer.c
> similarity index 100%
> rename from drivers/net/phy/mdio-mux-multiplexer.c
> rename to drivers/net/phy/mdio/mdio-mux-multiplexer.c
> diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio/mdio-mux.c
> similarity index 100%
> rename from drivers/net/phy/mdio-mux.c
> rename to drivers/net/phy/mdio/mdio-mux.c
> diff --git a/drivers/net/phy/mdio-mvusb.c b/drivers/net/phy/mdio/mdio-
> mvusb.c
> similarity index 100%
> rename from drivers/net/phy/mdio-mvusb.c
> rename to drivers/net/phy/mdio/mdio-mvusb.c
> diff --git a/drivers/net/phy/mdio-octeon.c b/drivers/net/phy/mdio/mdio-
> octeon.c
> similarity index 100%
> rename from drivers/net/phy/mdio-octeon.c
> rename to drivers/net/phy/mdio/mdio-octeon.c
> diff --git a/drivers/net/phy/mdio-sun4i.c b/drivers/net/phy/mdio/mdio-
> sun4i.c
> similarity index 100%
> rename from drivers/net/phy/mdio-sun4i.c
> rename to drivers/net/phy/mdio/mdio-sun4i.c
> diff --git a/drivers/net/phy/mdio-thunder.c b/drivers/net/phy/mdio/mdio-
> thunder.c
> similarity index 100%
> rename from drivers/net/phy/mdio-thunder.c
> rename to drivers/net/phy/mdio/mdio-thunder.c
> diff --git a/drivers/net/phy/mdio-xgene.c b/drivers/net/phy/mdio/mdio-
> xgene.c
> similarity index 100%
> rename from drivers/net/phy/mdio-xgene.c
> rename to drivers/net/phy/mdio/mdio-xgene.c
> diff --git a/drivers/net/phy/phy/Kconfig b/drivers/net/phy/phy/Kconfig
> new file mode 100644
> index 000000000000..51c01e51be34
> --- /dev/null
> +++ b/drivers/net/phy/phy/Kconfig
> @@ -0,0 +1,243 @@
> +config AMD_PHY
> + tristate "AMD PHYs"
> + help
> + Currently supports the am79c874
> +
> +config ADIN_PHY
> + tristate "Analog Devices Industrial Ethernet PHYs"
> + help
> + Adds support for the Analog Devices Industrial Ethernet PHYs.
> + Currently supports the:
> + - ADIN1200 - Robust,Industrial, Low Power 10/100 Ethernet PHY
> + - ADIN1300 - Robust,Industrial, Low Latency 10/100/1000 Gigabit
> + Ethernet PHY
> +
> +config MESON_GXL_PHY
> + tristate "Amlogic Meson GXL Internal PHY"
> + depends on ARCH_MESON || COMPILE_TEST
> + help
> + Currently has a driver for the Amlogic Meson GXL Internal PHY
> +
> +config AQUANTIA_PHY
> + tristate "Aquantia PHYs"
> + help
> + Currently supports the Aquantia AQ1202, AQ2104, AQR105, AQR405
> +
> +config AX88796B_PHY
> + tristate "Asix PHYs"
> + help
> + Currently supports the Asix Electronics PHY found in the X-Surf
> 100
> + AX88796B package.
> +
> +config BCM_NET_PHYLIB
> + tristate
> +
> +config BCM54140_PHY
> + tristate "Broadcom BCM54140 PHY"
> + depends on PHYLIB
> + depends on HWMON || HWMON=n
> + select BCM_NET_PHYLIB
> + help
> + Support the Broadcom BCM54140 Quad SGMII/QSGMII PHY.
> +
> + This driver also supports the hardware monitoring of this PHY and
> + exposes voltage and temperature sensors.
> +
> +config BROADCOM_PHY
> + tristate "Broadcom BCM5xxx PHYs"
> + select BCM_NET_PHYLIB
> + help
> + Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S,
> BCM5464,
> + BCM5481, BCM54810 and BCM5482 PHYs.
> +
> +config BCM63XX_PHY
> + tristate "Broadcom 63xx SOCs internal PHY"
> + depends on BCM63XX || COMPILE_TEST
> + select BCM_NET_PHYLIB
> + help
> + Currently supports the 6348 and 6358 PHYs.
> +
> +config BCM7XXX_PHY
> + tristate "Broadcom 7xxx SOCs internal PHYs"
> + select BCM_NET_PHYLIB
> + help
> + Currently supports the BCM7366, BCM7439, BCM7445, and
> + 40nm and 65nm generation of BCM7xxx Set Top Box SoCs.
> +
> +config BCM84881_PHY
> + tristate "Broadcom BCM84881 PHY"
> + depends on PHYLIB
> + help
> + Support the Broadcom BCM84881 PHY.
> +
> +config BCM87XX_PHY
> + tristate "Broadcom BCM8706 and BCM8727 PHYs"
> + help
> + Currently supports the BCM8706 and BCM8727 10G Ethernet PHYs.
> +
> +config BCM_CYGNUS_PHY
> + tristate "Broadcom Cygnus/Omega SoC internal PHY"
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + depends on MDIO_BCM_IPROC
> + select BCM_NET_PHYLIB
> + help
> + This PHY driver is for the 1G internal PHYs of the Broadcom
> + Cygnus and Omega Family SoC.
> +
> + Currently supports internal PHY's used in the BCM11300,
> + BCM11320, BCM11350, BCM11360, BCM58300, BCM58302,
> + BCM58303 & BCM58305 Broadcom Cygnus SoCs.
> +
> +config CICADA_PHY
> + tristate "Cicada PHYs"
> + help
> + Currently supports the cis8204
> +
> +config CORTINA_PHY
> + tristate "Cortina EDC CDR 10G Ethernet PHY"
> + help
> + Currently supports the CS4340 phy.
> +
> +config DAVICOM_PHY
> + tristate "Davicom PHYs"
> + help
> + Currently supports dm9161e and dm9131
> +
> +config ICPLUS_PHY
> + tristate "ICPlus PHYs"
> + help
> + Currently supports the IP175C and IP1001 PHYs.
> +
> +config INTEL_XWAY_PHY
> + tristate "Intel XWAY PHYs"
> + help
> + Supports the Intel XWAY (former Lantiq) 11G and 22E PHYs.
> + These PHYs are marked as standalone chips under the names
> + PEF 7061, PEF 7071 and PEF 7072 or integrated into the Intel
> + SoCs xRX200, xRX300, xRX330, xRX350 and xRX550.
> +
> +config LXT_PHY
> + tristate "Intel LXT PHYs"
> + help
> + Currently supports the lxt970, lxt971
> +
> +config LSI_ET1011C_PHY
> + tristate "LSI ET1011C PHY"
> + help
> + Supports the LSI ET1011C PHY.
> +
> +config MARVELL_PHY
> + tristate "Marvell Alaska 1Gbit PHYs"
> + help
> + Currently has a driver for the 88E1011S
> +
> +config MARVELL_10G_PHY
> + tristate "Marvell Alaska 10Gbit PHYs"
> + help
> + Support for the Marvell Alaska MV88X3310 and compatible PHYs.
> +
> +config MICREL_PHY
> + tristate "Micrel PHYs"
> + help
> + Supports the KSZ9021, VSC8201, KS8001 PHYs.
> +
> +config MICROCHIP_PHY
> + tristate "Microchip LAN88XX PHYs"
> + help
> + Supports the LAN88XX PHYs.
> +
> +config MICROCHIP_T1_PHY
> + tristate "Microchip LAN87xx T1 PHYs"
> + help
> + Supports the LAN87XX PHYs.
> +
> +config MICROSEMI_PHY
> + tristate "Microsemi PHYs"
> + depends on MACSEC || MACSEC=n
> + select CRYPTO_LIB_AES if MACSEC
> + help
> + Currently supports VSC8514, VSC8530, VSC8531, VSC8540 and VSC8541
> PHYs
> +
> +config NATIONAL_PHY
> + tristate "National Semiconductor PHYs"
> + help
> + Currently supports the DP83865 PHY.
> +
> +config NXP_TJA11XX_PHY
> + tristate "NXP TJA11xx PHYs support"
> + depends on HWMON
> + help
> + Currently supports the NXP TJA1100 and TJA1101 PHY.
> +
> +config AT803X_PHY
> + tristate "Qualcomm Atheros AR803X PHYs"
> + depends on REGULATOR
> + help
> + Currently supports the AR8030, AR8031, AR8033 and AR8035 model
> +
> +config QSEMI_PHY
> + tristate "Quality Semiconductor PHYs"
> + help
> + Currently supports the qs6612
> +
> +config REALTEK_PHY
> + tristate "Realtek PHYs"
> + help
> + Supports the Realtek 821x PHY.
> +
> +config RENESAS_PHY
> + tristate "Renesas PHYs"
> + help
> + Supports the Renesas PHYs uPD60620 and uPD60620A.
> +
> +config ROCKCHIP_PHY
> + tristate "Rockchip Ethernet PHYs"
> + help
> + Currently supports the integrated Ethernet PHY.
> +
> +config SMSC_PHY
> + tristate "SMSC PHYs"
> + help
> + Currently supports the LAN83C185, LAN8187 and LAN8700 PHYs
> +
> +config STE10XP
> + tristate "STMicroelectronics STe10Xp PHYs"
> + help
> + This is the driver for the STe100p and STe101p PHYs.
> +
> +config TERANETICS_PHY
> + tristate "Teranetics PHYs"
> + help
> + Currently supports the Teranetics TN2020
> +
> +config DP83822_PHY
> + tristate "Texas Instruments DP83822/825/826 PHYs"
> + help
> + Supports the DP83822, DP83825I, DP83825CM, DP83825CS, DP83825S,
> + DP83826C and DP83826NC PHYs.
> +
> +config DP83848_PHY
> + tristate "Texas Instruments DP83848 PHY"
> + help
> + Supports the DP83848 PHY.
> +
> +config DP83867_PHY
> + tristate "Texas Instruments DP83867 Gigabit PHY"
> + help
> + Currently supports the DP83867 PHY.
> +
> +config DP83869_PHY
> + tristate "Texas Instruments DP83869 Gigabit PHY"
> + help
> + Currently supports the DP83869 PHY. This PHY supports copper and
> + fiber connections.
> +
> +config DP83TC811_PHY
> + tristate "Texas Instruments DP83TC811 PHY"
> + help
> + Supports the DP83TC811 PHY.
> +
> +config VITESSE_PHY
> + tristate "Vitesse PHYs"
> + help
> + Currently supports the vsc8244
> diff --git a/drivers/net/phy/phy/Makefile b/drivers/net/phy/phy/Makefile
> new file mode 100644
> index 000000000000..f0c2b82c03ac
> --- /dev/null
> +++ b/drivers/net/phy/phy/Makefile
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Makefile for Linux PHY drivers
> +
> +obj-$(CONFIG_ADIN_PHY) += adin.o
> +obj-$(CONFIG_AMD_PHY) += amd.o
> +aquantia-objs += aquantia_main.o
> +ifdef CONFIG_HWMON
> +aquantia-objs += aquantia_hwmon.o
> +endif
> +obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
> +obj-$(CONFIG_AT803X_PHY) += at803x.o
> +obj-$(CONFIG_AX88796B_PHY) += ax88796b.o
> +obj-$(CONFIG_BCM54140_PHY) += bcm54140.o
> +obj-$(CONFIG_BCM63XX_PHY) += bcm63xx.o
> +obj-$(CONFIG_BCM7XXX_PHY) += bcm7xxx.o
> +obj-$(CONFIG_BCM84881_PHY) += bcm84881.o
> +obj-$(CONFIG_BCM87XX_PHY) += bcm87xx.o
> +obj-$(CONFIG_BCM_CYGNUS_PHY) += bcm-cygnus.o
> +obj-$(CONFIG_BCM_NET_PHYLIB) += bcm-phy-lib.o
> +obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
> +obj-$(CONFIG_CICADA_PHY) += cicada.o
> +obj-$(CONFIG_CORTINA_PHY) += cortina.o
> +obj-$(CONFIG_DAVICOM_PHY) += davicom.o
> +obj-$(CONFIG_DP83640_PHY) += dp83640.o
> +obj-$(CONFIG_DP83822_PHY) += dp83822.o
> +obj-$(CONFIG_DP83848_PHY) += dp83848.o
> +obj-$(CONFIG_DP83867_PHY) += dp83867.o
> +obj-$(CONFIG_DP83869_PHY) += dp83869.o
> +obj-$(CONFIG_DP83TC811_PHY) += dp83tc811.o
> +obj-$(CONFIG_ICPLUS_PHY) += icplus.o
> +obj-$(CONFIG_INTEL_XWAY_PHY) += intel-xway.o
> +obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
> +obj-$(CONFIG_LXT_PHY) += lxt.o
> +obj-$(CONFIG_MARVELL_10G_PHY) += marvell10g.o
> +obj-$(CONFIG_MARVELL_PHY) += marvell.o
> +obj-$(CONFIG_MESON_GXL_PHY) += meson-gxl.o
> +obj-$(CONFIG_MICREL_PHY) += micrel.o
> +obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
> +obj-$(CONFIG_MICROCHIP_T1_PHY) += microchip_t1.o
> +obj-$(CONFIG_MICROSEMI_PHY) += mscc/
> +obj-$(CONFIG_NATIONAL_PHY) += national.o
> +obj-$(CONFIG_NXP_TJA11XX_PHY) += nxp-tja11xx.o
> +obj-$(CONFIG_QSEMI_PHY) += qsemi.o
> +obj-$(CONFIG_REALTEK_PHY) += realtek.o
> +obj-$(CONFIG_RENESAS_PHY) += uPD60620.o
> +obj-$(CONFIG_ROCKCHIP_PHY) += rockchip.o
> +obj-$(CONFIG_SMSC_PHY) += smsc.o
> +obj-$(CONFIG_STE10XP) += ste10Xp.o
> +obj-$(CONFIG_TERANETICS_PHY) += teranetics.o
> +obj-$(CONFIG_VITESSE_PHY) += vitesse.o
> diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/phy/adin.c
> similarity index 100%
> rename from drivers/net/phy/adin.c
> rename to drivers/net/phy/phy/adin.c
> diff --git a/drivers/net/phy/amd.c b/drivers/net/phy/phy/amd.c
> similarity index 100%
> rename from drivers/net/phy/amd.c
> rename to drivers/net/phy/phy/amd.c
> diff --git a/drivers/net/phy/aquantia.h b/drivers/net/phy/phy/aquantia.h
> similarity index 100%
> rename from drivers/net/phy/aquantia.h
> rename to drivers/net/phy/phy/aquantia.h
> diff --git a/drivers/net/phy/aquantia_hwmon.c
> b/drivers/net/phy/phy/aquantia_hwmon.c
> similarity index 100%
> rename from drivers/net/phy/aquantia_hwmon.c
> rename to drivers/net/phy/phy/aquantia_hwmon.c
> diff --git a/drivers/net/phy/aquantia_main.c
> b/drivers/net/phy/phy/aquantia_main.c
> similarity index 100%
> rename from drivers/net/phy/aquantia_main.c
> rename to drivers/net/phy/phy/aquantia_main.c
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/phy/at803x.c
> similarity index 100%
> rename from drivers/net/phy/at803x.c
> rename to drivers/net/phy/phy/at803x.c
> diff --git a/drivers/net/phy/ax88796b.c b/drivers/net/phy/phy/ax88796b.c
> similarity index 100%
> rename from drivers/net/phy/ax88796b.c
> rename to drivers/net/phy/phy/ax88796b.c
> diff --git a/drivers/net/phy/bcm-cygnus.c b/drivers/net/phy/phy/bcm-
> cygnus.c
> similarity index 100%
> rename from drivers/net/phy/bcm-cygnus.c
> rename to drivers/net/phy/phy/bcm-cygnus.c
> diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/phy/bcm-phy-
> lib.c
> similarity index 100%
> rename from drivers/net/phy/bcm-phy-lib.c
> rename to drivers/net/phy/phy/bcm-phy-lib.c
> diff --git a/drivers/net/phy/bcm-phy-lib.h b/drivers/net/phy/phy/bcm-phy-
> lib.h
> similarity index 100%
> rename from drivers/net/phy/bcm-phy-lib.h
> rename to drivers/net/phy/phy/bcm-phy-lib.h
> diff --git a/drivers/net/phy/bcm54140.c b/drivers/net/phy/phy/bcm54140.c
> similarity index 100%
> rename from drivers/net/phy/bcm54140.c
> rename to drivers/net/phy/phy/bcm54140.c
> diff --git a/drivers/net/phy/bcm63xx.c b/drivers/net/phy/phy/bcm63xx.c
> similarity index 100%
> rename from drivers/net/phy/bcm63xx.c
> rename to drivers/net/phy/phy/bcm63xx.c
> diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/phy/bcm7xxx.c
> similarity index 100%
> rename from drivers/net/phy/bcm7xxx.c
> rename to drivers/net/phy/phy/bcm7xxx.c
> diff --git a/drivers/net/phy/bcm84881.c b/drivers/net/phy/phy/bcm84881.c
> similarity index 100%
> rename from drivers/net/phy/bcm84881.c
> rename to drivers/net/phy/phy/bcm84881.c
> diff --git a/drivers/net/phy/bcm87xx.c b/drivers/net/phy/phy/bcm87xx.c
> similarity index 100%
> rename from drivers/net/phy/bcm87xx.c
> rename to drivers/net/phy/phy/bcm87xx.c
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/phy/broadcom.c
> similarity index 100%
> rename from drivers/net/phy/broadcom.c
> rename to drivers/net/phy/phy/broadcom.c
> diff --git a/drivers/net/phy/cicada.c b/drivers/net/phy/phy/cicada.c
> similarity index 100%
> rename from drivers/net/phy/cicada.c
> rename to drivers/net/phy/phy/cicada.c
> diff --git a/drivers/net/phy/cortina.c b/drivers/net/phy/phy/cortina.c
> similarity index 100%
> rename from drivers/net/phy/cortina.c
> rename to drivers/net/phy/phy/cortina.c
> diff --git a/drivers/net/phy/davicom.c b/drivers/net/phy/phy/davicom.c
> similarity index 100%
> rename from drivers/net/phy/davicom.c
> rename to drivers/net/phy/phy/davicom.c
> diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/phy/dp83640.c
> similarity index 100%
> rename from drivers/net/phy/dp83640.c
> rename to drivers/net/phy/phy/dp83640.c
> diff --git a/drivers/net/phy/dp83640_reg.h
> b/drivers/net/phy/phy/dp83640_reg.h
> similarity index 100%
> rename from drivers/net/phy/dp83640_reg.h
> rename to drivers/net/phy/phy/dp83640_reg.h
> diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/phy/dp83822.c
> similarity index 100%
> rename from drivers/net/phy/dp83822.c
> rename to drivers/net/phy/phy/dp83822.c
> diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/phy/dp83848.c
> similarity index 100%
> rename from drivers/net/phy/dp83848.c
> rename to drivers/net/phy/phy/dp83848.c
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/phy/dp83867.c
> similarity index 100%
> rename from drivers/net/phy/dp83867.c
> rename to drivers/net/phy/phy/dp83867.c
> diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/phy/dp83869.c
> similarity index 100%
> rename from drivers/net/phy/dp83869.c
> rename to drivers/net/phy/phy/dp83869.c
> diff --git a/drivers/net/phy/dp83tc811.c b/drivers/net/phy/phy/dp83tc811.c
> similarity index 100%
> rename from drivers/net/phy/dp83tc811.c
> rename to drivers/net/phy/phy/dp83tc811.c
> diff --git a/drivers/net/phy/et1011c.c b/drivers/net/phy/phy/et1011c.c
> similarity index 100%
> rename from drivers/net/phy/et1011c.c
> rename to drivers/net/phy/phy/et1011c.c
> diff --git a/drivers/net/phy/icplus.c b/drivers/net/phy/phy/icplus.c
> similarity index 100%
> rename from drivers/net/phy/icplus.c
> rename to drivers/net/phy/phy/icplus.c
> diff --git a/drivers/net/phy/intel-xway.c b/drivers/net/phy/phy/intel-
> xway.c
> similarity index 100%
> rename from drivers/net/phy/intel-xway.c
> rename to drivers/net/phy/phy/intel-xway.c
> diff --git a/drivers/net/phy/lxt.c b/drivers/net/phy/phy/lxt.c
> similarity index 100%
> rename from drivers/net/phy/lxt.c
> rename to drivers/net/phy/phy/lxt.c
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/phy/marvell.c
> similarity index 100%
> rename from drivers/net/phy/marvell.c
> rename to drivers/net/phy/phy/marvell.c
> diff --git a/drivers/net/phy/marvell10g.c
> b/drivers/net/phy/phy/marvell10g.c
> similarity index 100%
> rename from drivers/net/phy/marvell10g.c
> rename to drivers/net/phy/phy/marvell10g.c
> diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/phy/meson-gxl.c
> similarity index 100%
> rename from drivers/net/phy/meson-gxl.c
> rename to drivers/net/phy/phy/meson-gxl.c
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/phy/micrel.c
> similarity index 100%
> rename from drivers/net/phy/micrel.c
> rename to drivers/net/phy/phy/micrel.c
> diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/phy/microchip.c
> similarity index 100%
> rename from drivers/net/phy/microchip.c
> rename to drivers/net/phy/phy/microchip.c
> diff --git a/drivers/net/phy/microchip_t1.c
> b/drivers/net/phy/phy/microchip_t1.c
> similarity index 100%
> rename from drivers/net/phy/microchip_t1.c
> rename to drivers/net/phy/phy/microchip_t1.c
> diff --git a/drivers/net/phy/mscc/Makefile
> b/drivers/net/phy/phy/mscc/Makefile
> similarity index 100%
> rename from drivers/net/phy/mscc/Makefile
> rename to drivers/net/phy/phy/mscc/Makefile
> diff --git a/drivers/net/phy/mscc/mscc.h b/drivers/net/phy/phy/mscc/mscc.h
> similarity index 100%
> rename from drivers/net/phy/mscc/mscc.h
> rename to drivers/net/phy/phy/mscc/mscc.h
> diff --git a/drivers/net/phy/mscc/mscc_fc_buffer.h
> b/drivers/net/phy/phy/mscc/mscc_fc_buffer.h
> similarity index 100%
> rename from drivers/net/phy/mscc/mscc_fc_buffer.h
> rename to drivers/net/phy/phy/mscc/mscc_fc_buffer.h
> diff --git a/drivers/net/phy/mscc/mscc_mac.h
> b/drivers/net/phy/phy/mscc/mscc_mac.h
> similarity index 100%
> rename from drivers/net/phy/mscc/mscc_mac.h
> rename to drivers/net/phy/phy/mscc/mscc_mac.h
> diff --git a/drivers/net/phy/mscc/mscc_macsec.c
> b/drivers/net/phy/phy/mscc/mscc_macsec.c
> similarity index 100%
> rename from drivers/net/phy/mscc/mscc_macsec.c
> rename to drivers/net/phy/phy/mscc/mscc_macsec.c
> diff --git a/drivers/net/phy/mscc/mscc_macsec.h
> b/drivers/net/phy/phy/mscc/mscc_macsec.h
> similarity index 100%
> rename from drivers/net/phy/mscc/mscc_macsec.h
> rename to drivers/net/phy/phy/mscc/mscc_macsec.h
> diff --git a/drivers/net/phy/mscc/mscc_main.c
> b/drivers/net/phy/phy/mscc/mscc_main.c
> similarity index 100%
> rename from drivers/net/phy/mscc/mscc_main.c
> rename to drivers/net/phy/phy/mscc/mscc_main.c
> diff --git a/drivers/net/phy/national.c b/drivers/net/phy/phy/national.c
> similarity index 100%
> rename from drivers/net/phy/national.c
> rename to drivers/net/phy/phy/national.c
> diff --git a/drivers/net/phy/nxp-tja11xx.c b/drivers/net/phy/phy/nxp-
> tja11xx.c
> similarity index 100%
> rename from drivers/net/phy/nxp-tja11xx.c
> rename to drivers/net/phy/phy/nxp-tja11xx.c
> diff --git a/drivers/net/phy/qsemi.c b/drivers/net/phy/phy/qsemi.c
> similarity index 100%
> rename from drivers/net/phy/qsemi.c
> rename to drivers/net/phy/phy/qsemi.c
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/phy/realtek.c
> similarity index 100%
> rename from drivers/net/phy/realtek.c
> rename to drivers/net/phy/phy/realtek.c
> diff --git a/drivers/net/phy/rockchip.c b/drivers/net/phy/phy/rockchip.c
> similarity index 100%
> rename from drivers/net/phy/rockchip.c
> rename to drivers/net/phy/phy/rockchip.c
> diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/phy/smsc.c
> similarity index 100%
> rename from drivers/net/phy/smsc.c
> rename to drivers/net/phy/phy/smsc.c
> diff --git a/drivers/net/phy/ste10Xp.c b/drivers/net/phy/phy/ste10Xp.c
> similarity index 100%
> rename from drivers/net/phy/ste10Xp.c
> rename to drivers/net/phy/phy/ste10Xp.c
> diff --git a/drivers/net/phy/teranetics.c
> b/drivers/net/phy/phy/teranetics.c
> similarity index 100%
> rename from drivers/net/phy/teranetics.c
> rename to drivers/net/phy/phy/teranetics.c
> diff --git a/drivers/net/phy/uPD60620.c b/drivers/net/phy/phy/uPD60620.c
> similarity index 100%
> rename from drivers/net/phy/uPD60620.c
> rename to drivers/net/phy/phy/uPD60620.c
> diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/phy/vitesse.c
> similarity index 100%
> rename from drivers/net/phy/vitesse.c
> rename to drivers/net/phy/phy/vitesse.c
> --
> 2.28.0.rc0
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
From: Russell King - ARM Linux admin @ 2020-08-03 14:10 UTC (permalink / raw)
To: Madalin Bucur (OSS)
Cc: Andrew Lunn, Vikas Singh, f.fainelli@gmail.com,
hkallweit1@gmail.com, netdev@vger.kernel.org,
Calvin Johnson (OSS), kuldip dwivedi, Vikas Singh
In-Reply-To: <AM6PR04MB3976284AEC94129D26300485EC4D0@AM6PR04MB3976.eurprd04.prod.outlook.com>
On Mon, Aug 03, 2020 at 11:45:55AM +0000, Madalin Bucur (OSS) wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > Sent: 03 August 2020 12:07
> > To: Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>
> > Cc: Andrew Lunn <andrew@lunn.ch>; Vikas Singh
> > <vikas.singh@puresoftware.com>; f.fainelli@gmail.com; hkallweit1@gmail.com;
> > netdev@vger.kernel.org; Calvin Johnson (OSS) <calvin.johnson@oss.nxp.com>;
> > kuldip dwivedi <kuldip.dwivedi@puresoftware.com>; Vikas Singh
> > <vikas.singh@nxp.com>
> > Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
> >
> > On Mon, Aug 03, 2020 at 08:33:19AM +0000, Madalin Bucur (OSS) wrote:
> > > > -----Original Message-----
> > > > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> > > > Behalf Of Andrew Lunn
> > > > Sent: 01 August 2020 18:11
> > > > To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > > > Cc: Vikas Singh <vikas.singh@puresoftware.com>; f.fainelli@gmail.com;
> > > > hkallweit1@gmail.com; netdev@vger.kernel.org; Calvin Johnson (OSS)
> > > > <calvin.johnson@oss.nxp.com>; kuldip dwivedi
> > > > <kuldip.dwivedi@puresoftware.com>; Madalin Bucur (OSS)
> > > > <madalin.bucur@oss.nxp.com>; Vikas Singh <vikas.singh@nxp.com>
> > > > Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed
> > PHY
> > > >
> > > > On Sat, Aug 01, 2020 at 10:41:32AM +0100, Russell King - ARM Linux
> > admin
> > > > wrote:
> > > > > On Sat, Aug 01, 2020 at 09:52:52AM +0530, Vikas Singh wrote:
> > > > > > Hi Andrew,
> > > > > >
> > > > > > Please refer to the "fman" node under
> > > > > > linux/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > > > > > I have two 10G ethernet interfaces out of which one is of fixed-
> > link.
> > > > >
> > > > > Please do not top post.
> > > > >
> > > > > How does XGMII (which is a 10G only interface) work at 1G speed? Is
> > > > > what is in DT itself a hack because fixed-phy doesn't support 10G
> > > > > modes?
> > > >
> > > > My gut feeling is there is some hack going on here, which is why i'm
> > > > being persistent at trying to understand what is actually going on
> > > > here.
> > >
> > > Hi Andrew,
> > >
> > > That platform used 1G fixed link there since there was no support for
> > > 10G fixed link at the time. PHYlib could have tolerated 10G speed there
> > > With a one-liner.
> >
> > That statement is false. It is not a "one liner". fixed-phy exposes
> > the settings to userspace as a Clause 22 PHY register set, and the
> > Clause 22 register set does not support 10G. So, a "one liner" would
> > just be yet another hack. Adding Clause 45 PHY emulation support
> > would be a huge task.
> >
> > > I understand that PHYLink is working to describe this
> > > Better, but it was not there at that time. Adding the dependency on
> > > PHYLink was not desirable as most of the users for the DPAA 1 platforms
> > > were targeting kernels before the PHYLink introduction (and last I've
> > > looked, it's still under development, with unstable APIs so we'll
> > > take a look at this later, when it settles).
> >
> > I think you need to read Documentation/process/stable-api-nonsense.rst
> > particularly the section "Stable Kernel Source Interfaces".
> >
> > phylink is going to be under development for quite some time to come
> > as requirements evolve. For example, when support for QSFP interfaces
> > is eventually worked out, I suspect there will need to be some further
> > changes to the driver interface. This is completely normal.
> >
> > Now, as to the stability of the phylink API to drivers, it has in fact
> > been very stable - it has only changed over the course of this year to
> > support split PCS, a necessary step for DPAA2 and a few others. It has
> > been around in mainline for two years, and has been around much longer
> > than that, and during that time it has been in mainline, the MAC facing
> > interface has not changed until recently.
> >
> > So, I find your claim to be quite unreasonable.
>
> I see you agree that there were and there will be many changes for a while,
> It's not a complaint, I know hot it works, it's just a decision based on
> required effort vs features offered vs user requirements. Lately it's been
> time consuming to try to fix things in this area.
No, it hasn't been time consuming. The only API changes as far as
drivers are concerned have been:
1. the change to the mac_link_up() prototype to move the setup of the
final link parameters out of mac_config() - and almost all of the
updates to users were done by me.
2. the addition of split PCS support, introducing new interfaces, has
had minimal impact on those drivers that updated in step (1).
There have been no other changes as far as users are concerned.
Some of the difficulty with (1) has been that users of phylink appeared
initially with no proper review, and consequently they got quite a lot
wrong. The most common error has been using state->speed, state->duplex
in mac_config() methods irrespective of the AN mode, which has _always_
since before phylink was merged into mainline, been totally unreliable.
That leads me on to the other visible "changes" for users are concerned,
which may be interpreted as interface changes, but are not; they have
all been clarifications to the documentation, to strengthen things such
as "do not use state->speed and state->duplex in mac_config() for
various specific AN modes". Nothing has actually changed with any of
those clarifications.
For example, if in in-band mode, and mac_config() uses state->speed
and state->duplex, then it doesn't matter which version of phylink
you're using, if someone issues ethtool -s ethN ..., then state->speed
and state->duplex will be their respective UNKNOWN values, and if you're
using these in that situation, you will mis-program the MAC.
Again, that is not something that has changed. Ever. But the
documentation has because people just don't seem to get it, and I seemed
to be constantly repeating myself in review after review on the same
points.
So, your assertion that the phylink API is not stable is false. It
has been remarkably stable over the two years that it has been around.
It is only natural that as the technology that a piece of code supports
evolves, so the code evolves with it. That is exactly what has happened
this year with the two changes I mention above.
Now, if you've found it time consuming to "fix things" (unspecified what
"things" are) then I assert that what has needed to be fixed are things
that NXP have got wrong. Such as the rtnl cockups. Such as abusing
state->speed and state->duplex. None of that is because the interface
is unstable - they are down to buggy implementation on NXPs part.
Essentially, what I'm saying is that your attempt to paint phylink as
being painful on the basis of interface changes is totally and utterly
wrong and is just an excuse to justify abusing the fixed-link code and
specifying things that are clearly incorrect via DT.
I will accept that the interface that had existed up until the
mac_link_up() change was confusing - it clearly was due to the number
of people getting mac_config() implementations wrong. That is actually
another of the reasons why the mac_link_up() change was made. These
problems are _only_ found by people making use of it. If people don't
use stuff, then problems aren't found, and nothing changes.
So, I think you can expect a NAK for the patch at the top of this
thread on the basis that it is perpetuating an abuse not only the
legacy fixed-link code, but also DT. However, I will leave Andrew to
make that call.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* bpf-next is CLOSED
From: Daniel Borkmann @ 2020-08-03 14:08 UTC (permalink / raw)
To: bpf; +Cc: netdev, alexei.starovoitov, davem
The merge window is open right now, therefore please send bug fixes only at this
point. bpf-next will open back up in roughly 2 weeks after the merge window is
closed.
The last bpf-next PR will go out today to David after processing pending BPF items
from patchwork.
Thank you,
Daniel
^ permalink raw reply
* Re: [PATCH net-next] tipc: Use is_broadcast_ether_addr() instead of memcmp()
From: Ying Xue @ 2020-08-03 13:51 UTC (permalink / raw)
To: Huang Guobin, jmaloy, davem, kuba; +Cc: netdev, tipc-discussion, linux-kernel
In-Reply-To: <20200803020055.26822-1-huangguobin4@huawei.com>
On 8/3/20 10:00 AM, Huang Guobin wrote:
> Using is_broadcast_ether_addr() instead of directly use
> memcmp() to determine if the ethernet address is broadcast
> address.
>
> spatch with a semantic match is used to found this problem.
> (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Huang Guobin <huangguobin4@huawei.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
> ---
> net/tipc/eth_media.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/tipc/eth_media.c b/net/tipc/eth_media.c
> index 8b0bb600602d..c68019697cfe 100644
> --- a/net/tipc/eth_media.c
> +++ b/net/tipc/eth_media.c
> @@ -62,12 +62,10 @@ static int tipc_eth_raw2addr(struct tipc_bearer *b,
> struct tipc_media_addr *addr,
> char *msg)
> {
> - char bcast_mac[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
> -
> memset(addr, 0, sizeof(*addr));
> ether_addr_copy(addr->value, msg);
> addr->media_id = TIPC_MEDIA_TYPE_ETH;
> - addr->broadcast = !memcmp(addr->value, bcast_mac, ETH_ALEN);
> + addr->broadcast = is_broadcast_ether_addr(addr->value);
> return 0;
> }
>
>
^ permalink raw reply
* Re: 答复: [PATCH] qmi_wwan: support modify usbnet's rx_urb_size
From: Bjørn Mork @ 2020-08-03 14:05 UTC (permalink / raw)
To: Carl Yin(殷张成)
Cc: Daniele Palmas, Greg KH, yzc666@netease.com, David Miller,
kuba@kernel.org, netdev@vger.kernel.org, linux-usb
In-Reply-To: <HK2PR06MB3507C4CD349BBD29C68F3FCE864D0@HK2PR06MB3507.apcprd06.prod.outlook.com>
"Carl Yin(殷张成)" <carl.yin@quectel.com> writes:
> Hi Bjørn,
> You can check cdc_ncm.c.
> cdc ncm driver set 'rx_urb_size' on driver probe time, and the value read from' cdc_ncm_bind_common() 's USB_CDC_GET_NTB_FORMAT '.
> and also allow the userspace to modify 'rx_urb_size' by ' /sys/class/net/wwan0/cdc_ncm/rx_max'.
And I must admit I wrote that code ;-)
NCM has the concept of 'dwNtbInMaxSize' and 'dwNtbOutMaxSize'
controlling the maximum USB buffer size in each direction. The values
are set by the device and provided to the host driver when probing. The
driver then knows it must be prepared to receive up to 'dwNtbInMaxSize'
buffers and set 'rx_urb_size' to this value.
This is fully automatic and will Just Work without user/userspace
intervention for any sane NCM or MBIM device.
'rx_max' was introduced to handle the insane devices, wanting buffers
larger than the host was prepared to give them. The limit used to be
hard coded in the driver. But it was enough for some low end
hosts, so I made it configurable using that sysfs knob.
You are right that the rmnet aggregation situation is similar. But
similar to NCM, I would like a solution which is fully automatic for
most of the users. Or preferably all, if possible. A sysfs knob is a
last resort thing. Let's try to do without it first.
Bjørn
^ permalink raw reply
* Re: [PATCH v6 bpf-next 0/6] bpf: tailcalls in BPF subprograms
From: Daniel Borkmann @ 2020-08-03 14:00 UTC (permalink / raw)
To: Alexei Starovoitov, Maciej Fijalkowski
Cc: ast, bpf, netdev, bjorn.topel, magnus.karlsson
In-Reply-To: <20200802030752.bnebgrr6jkl3dgnk@ast-mbp.dhcp.thefacebook.com>
On 8/2/20 5:07 AM, Alexei Starovoitov wrote:
> On Sat, Aug 01, 2020 at 09:13:57AM +0200, Maciej Fijalkowski wrote:
>> On Sat, Aug 01, 2020 at 03:03:19AM +0200, Daniel Borkmann wrote:
>>> On 7/31/20 2:03 AM, Maciej Fijalkowski wrote:
>>>> v5->v6:
>>>> - propagate only those poke descriptors that individual subprogram is
>>>> actually using (Daniel)
>>>> - drop the cumbersome check if poke desc got filled in map_poke_run()
>>>> - move poke->ip renaming in bpf_jit_add_poke_descriptor() from patch 4
>>>> to patch 3 to provide bisectability (Daniel)
>>>
>>> I did a basic test with Cilium on K8s with this set, spawning a few Pods
>>> and checking connectivity & whether we're not crashing since it has bit more
>>> elaborate tail call use. So far so good. I was inclined to push the series
>>> out, but there is one more issue I noticed and didn't notice earlier when
>>> reviewing, and that is overall stack size:
>>>
>>> What happens when you create a single program that has nested BPF to BPF
>>> calls e.g. either up to the maximum nesting or one call that is using up
>>> the max stack size which is then doing another BPF to BPF call that contains
>>> the tail call. In the tail call map, you have the same program in there.
>>> This means we create a worst case stack from BPF size of max_stack_size *
>>> max_tail_call_size, that is, 512*32. So that adds 16k worst case. For x86
>>> we have a stack of arch/x86/include/asm/page_64_types.h:
>>>
>>> #define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER)
>>> #define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
>>>
>>> So we end up with 16k in a typical case. And this will cause kernel stack
>>> overflow; I'm at least not seeing where we handle this situation in the
>
> Not quite. The subprog is always 32 byte stack (from safety pov).
> The real stack (when JITed) can be lower or zero.
> So the max stack is (512 - 32) * 32 = 15360.
> So there is no overflow, but may be a bit too close to comfort.
I did a check with adding `stack_not_used(current)` to various points which
provides some useful data under CONFIG_DEBUG_STACK_USAGE. From tc ingress side
I'm getting roughly 13k free stack space which is definitely less than 15k even
at tc layer. I also checked on sk_filter_trim_cap() on ingress and worst case I
saw is very close to 12k, so a malicious or by accident a buggy program would be
able to cause a stack overflow as-is.
> Imo the room is ok to land the set and the better enforcement can
> be done as a follow up later, like below idea...
>
>>> set. Hm, need to think more, but maybe this needs tracking of max stack
>>> across tail calls to force an upper limit..
>>
>> My knee jerk reaction would be to decrement the allowed max tail calls,
>> but not sure if it's an option and if it would help.
>
> How about make the verifier use a lower bound for a function with a tail call ?
> Something like 64 would work.
> subprog_info[idx].stack_depth with tail_call will be >= 64.
> Then the main function will be automatically limited to 512-64 and the worst
> case stack = 14kbyte.
Even 14k is way too close, see above. Some archs that are supported by the kernel
run under 8k total stack size. In the long run if more archs would support tail
calls with bpf-to-bpf calls, we might need a per-arch upper cap, but I think in
this context here an upper total cap on x86 that is 4k should be reasonable, it
sounds broken to me if more is indeed needed for the vast majority of use cases.
> When the sub prog with tail call is not an empty body (malicious stack
> abuser) then the lower bound won't affect anything.
> A bit annoying that stack_depth will be used by JIT to actually allocate
> that much. Some of it will not be used potentially, but I think it's fine.
> It's much simpler solution than to keep two variables to track stack size.
> Or may be check_max_stack_depth() can be a bit smarter and it can detect
> that subprog is using tail_call without actually hacking stack_depth variable.
+1, I think that would be better, maybe we could have a different cost function
for the tail call counter itself depending in which call-depth we are, but that
also requires two vars for tracking (tail call counter, call depth counter), so
more JIT changes & emitted insns required. :/ Otoh, what if tail call counter
is limited to 4k and we subtract stack usage instead with a min cost (e.g. 128)
if progs use less than that? Though the user experience will be really bad in
this case given these semantics feel less deterministic / hard to debug from
user PoV.
> Essentially I'm proposing to tweak this formula:
> depth += round_up(max_t(u32, subprog[idx].stack_depth, 1), 32);
> and replace 1 with 64 for subprogs with tail_call.
>
^ permalink raw reply
* Re: [PATCH ethtool 0/7] compiler warnings cleanup, part 1
From: Michal Kubecek @ 2020-08-03 13:53 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20200803133125.GN1862409@lunn.ch>
On Mon, Aug 03, 2020 at 03:31:25PM +0200, Andrew Lunn wrote:
> On Mon, Aug 03, 2020 at 01:57:03PM +0200, Michal Kubecek wrote:
> > Maciej Żenczykowski recently cleaned up many "unused parameter" compiler
> > warnings but some new occurences appeared since (mostly in netlink code).
>
> Hi Michal
>
> Could you modify the compiler flags to get gcc to warn about these?
> Otherwise they will just come back again.
Good point. I'll add "-Wextra" to default CFLAGS in Makefile.am with the
second part of the cleanup (shortly after 5.8 release). At that point
there will be no warnings so that it will be easy to spot any new ones.
Michal
^ permalink raw reply
* Re: [PATCH net-next RFC 00/13] Add devlink reload level option
From: Moshe Shemesh @ 2020-08-03 13:52 UTC (permalink / raw)
To: Vasundhara Volam
Cc: Jacob Keller, David S. Miller, Jiri Pirko, Netdev, open list
In-Reply-To: <CAACQVJpZZPfiWszZ36E0Awuo2Ad1w5=4C1rgG=d4qPiWVP609Q@mail.gmail.com>
On 8/3/2020 3:47 PM, Vasundhara Volam wrote:
> On Mon, Aug 3, 2020 at 5:47 PM Moshe Shemesh <moshe@mellanox.com> wrote:
>>
>> On 8/3/2020 1:24 PM, Vasundhara Volam wrote:
>>> On Tue, Jul 28, 2020 at 10:13 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
>>>>
>>>> On 7/27/2020 10:25 PM, Vasundhara Volam wrote:
>>>>> On Mon, Jul 27, 2020 at 4:36 PM Moshe Shemesh <moshe@mellanox.com> wrote:
>>>>>> Introduce new option on devlink reload API to enable the user to select the
>>>>>> reload level required. Complete support for all levels in mlx5.
>>>>>> The following reload levels are supported:
>>>>>> driver: Driver entities re-instantiation only.
>>>>>> fw_reset: Firmware reset and driver entities re-instantiation.
>>>>> The Name is a little confusing. I think it should be renamed to
>>>>> fw_live_reset (in which both firmware and driver entities are
>>>>> re-instantiated). For only fw_reset, the driver should not undergo
>>>>> reset (it requires a driver reload for firmware to undergo reset).
>>>>>
>>>> So, I think the differentiation here is that "live_patch" doesn't reset
>>>> anything.
>>> This seems similar to flashing the firmware and does not reset anything.
>>
>> The live patch is activating fw change without reset.
>>
>> It is not suitable for any fw change but fw gaps which don't require reset.
>>
>> I can query the fw to check if the pending image change is suitable or
>> require fw reset.
> Okay.
>>>>>> fw_live_patch: Firmware live patching only.
>>>>> This level is not clear. Is this similar to flashing??
>>>>>
>>>>> Also I have a basic query. The reload command is split into
>>>>> reload_up/reload_down handlers (Please correct me if this behaviour is
>>>>> changed with this patchset). What if the vendor specific driver does
>>>>> not support up/down and needs only a single handler to fire a firmware
>>>>> reset or firmware live reset command?
>>>> In the "reload_down" handler, they would trigger the appropriate reset,
>>>> and quiesce anything that needs to be done. Then on reload up, it would
>>>> restore and bring up anything quiesced in the first stage.
>>> Yes, I got the "reload_down" and "reload_up". Similar to the device
>>> "remove" and "re-probe" respectively.
>>>
>>> But our requirement is a similar "ethtool reset" command, where
>>> ethtool calls a single callback in driver and driver just sends a
>>> firmware command for doing the reset. Once firmware receives the
>>> command, it will initiate the reset of driver and firmware entities
>>> asynchronously.
>>
>> It is similar to mlx5 case here for fw_reset. The driver triggers the fw
>> command to reset and all PFs drivers gets events to handle and do
>> re-initialization. To fit it to the devlink reload_down and reload_up,
>> I wait for the event handler to complete and it stops at driver unload
>> to have the driver up by devlink reload_up. See patch 8 in this patchset.
>>
> Yes, I see reload_down is triggering the reset. In our driver, after
> triggering the reset through a firmware command, reset is done in
> another context as the driver initiates the reset only after receiving
> an ASYNC event from the firmware.
Same here.
>
> Probably, we have to use reload_down() to send firmware command to
> trigger reset and do nothing in reload_up.
I had that in previous version, but its wrong to use devlink reload this
way, so I added wait with timeout for the event handling to complete
before unload_down function ends. See mlx5_fw_wait_fw_reset_done(). Also
the event handler stops before load back to have that done by devlink
reload_up.
> And returning from reload
> does not mean that reset is complete as it is done in another context
> and the driver notifies the health reporter once the reset is
> complete. devlink framework may have to allow drivers to implement
> reload_down only to look more clean or call reload_up only if the
> driver notifies the devlink once reset is completed from another
> context. Please suggest.
^ permalink raw reply
* Re: PMTUD broken inside network namespace with multipath routing
From: David Ahern @ 2020-08-03 13:32 UTC (permalink / raw)
To: mastertheknife, netdev
In-Reply-To: <CANXY5y+iuzMg+4UdkPJW_Efun30KAPL1+h2S7HeSPp4zOrVC7g@mail.gmail.com>
On 8/3/20 5:14 AM, mastertheknife wrote:
> What seems to be happening, is that when multipath routing is used
> inside LXC (or any network namespace), the kernel doesn't generate a
> routing exception to force the lower MTU.
> I believe this is a bug inside the kernel.
>
Known problem. Original message can take path 1 and ICMP message can
path 2. The exception is then created on the wrong path.
^ permalink raw reply
* Re: [PATCH v4 09/11] net: dsa: microchip: Add Microchip KSZ8863 SMI based driver support
From: Randy Dunlap @ 2020-08-03 13:31 UTC (permalink / raw)
To: Michael Grzeschik, andrew; +Cc: netdev, f.fainelli, davem, kernel
In-Reply-To: <20200803054442.20089-10-m.grzeschik@pengutronix.de>
On 8/2/20 10:44 PM, Michael Grzeschik wrote:
> diff --git a/drivers/net/dsa/microchip/Kconfig b/drivers/net/dsa/microchip/Kconfig
> index 4ec6a47b7f7284f..c5819bd4121cc7c 100644
> --- a/drivers/net/dsa/microchip/Kconfig
> +++ b/drivers/net/dsa/microchip/Kconfig
> @@ -40,3 +40,12 @@ config NET_DSA_MICROCHIP_KSZ8795_SPI
>
> It is required to use the KSZ8795 switch driver as the only access
> is through SPI.
> +
> +config NET_DSA_MICROCHIP_KSZ8863_SMI
> + tristate "KSZ series SMI connected switch driver"
> + depends on NET_DSA_MICROCHIP_KSZ8795
> + select MDIO_BITBANG
> + default y
huh? why?
> + help
> + Select to enable support for registering switches configured through
> + Microchip SMI. It Supports the KSZ8863 and KSZ8873 Switch.
supports switch.
--
~Randy
^ permalink raw reply
* Re: [PATCH ethtool 0/7] compiler warnings cleanup, part 1
From: Andrew Lunn @ 2020-08-03 13:31 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev
In-Reply-To: <cover.1596451857.git.mkubecek@suse.cz>
On Mon, Aug 03, 2020 at 01:57:03PM +0200, Michal Kubecek wrote:
> Maciej Żenczykowski recently cleaned up many "unused parameter" compiler
> warnings but some new occurences appeared since (mostly in netlink code).
Hi Michal
Could you modify the compiler flags to get gcc to warn about these?
Otherwise they will just come back again.
Andrew
^ permalink raw reply
* [PATCH ethtool] ethtool.spec: Add bash completion script
From: Roi Dayan @ 2020-08-03 13:23 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, Roi Dayan
After the additon of the bash completion script, packaging
using the default spec file fails for installed but not packaged
error. so package it.
Fixes: 9b802643d7bd ("ethtool: Add bash-completion script")
Signed-off-by: Roi Dayan <roid@mellanox.com>
---
ethtool.spec.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/ethtool.spec.in b/ethtool.spec.in
index 9c01b07abf2b..75f9be6aafa6 100644
--- a/ethtool.spec.in
+++ b/ethtool.spec.in
@@ -34,6 +34,7 @@ make install DESTDIR=${RPM_BUILD_ROOT}
%defattr(-,root,root)
%{_sbindir}/ethtool
%{_mandir}/man8/ethtool.8*
+%{_datadir}/bash-completion/completions/ethtool
%doc AUTHORS COPYING NEWS README
--
2.8.4
^ permalink raw reply related
* [PATCH net-next] fib: Fix undef compile warning
From: YueHaibing @ 2020-08-03 13:19 UTC (permalink / raw)
To: davem, kuba, brianvv, rdunlap; +Cc: netdev, linux-kernel, YueHaibing
net/core/fib_rules.c:26:7: warning: "CONFIG_IP_MULTIPLE_TABLES" is not defined, evaluates to 0 [-Wundef]
#elif CONFIG_IP_MULTIPLE_TABLES
^~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 8b66a6fd34f5 ("fib: fix another fib_rules_ops indirect call wrapper problem")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/core/fib_rules.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index a7a3f500a857..51678a528f85 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -23,7 +23,7 @@
#else
#define INDIRECT_CALL_MT(f, f2, f1, ...) INDIRECT_CALL_1(f, f2, __VA_ARGS__)
#endif
-#elif CONFIG_IP_MULTIPLE_TABLES
+#elif defined(CONFIG_IP_MULTIPLE_TABLES)
#define INDIRECT_CALL_MT(f, f2, f1, ...) INDIRECT_CALL_1(f, f1, __VA_ARGS__)
#else
#define INDIRECT_CALL_MT(f, f2, f1, ...) f(__VA_ARGS__)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net v2 1/2] netfilter: conntrack: Move nf_ct_offload_timeout to header file
From: Roi Dayan @ 2020-08-03 13:15 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netdev, Paul Blakey, Oz Shlomo, Marcelo Ricardo Leitner
In-Reply-To: <20200803103916.GB2903@salvia>
On 2020-08-03 2:03 PM, Pablo Neira Ayuso wrote:
> On Mon, Aug 03, 2020 at 10:33:04AM +0300, Roi Dayan wrote:
>> To be used by callers from other modules.
>>
>> Signed-off-by: Roi Dayan <roid@mellanox.com>
>> Reviewed-by: Oz Shlomo <ozsh@mellanox.com>
>> ---
>> include/net/netfilter/nf_conntrack.h | 12 ++++++++++++
>> net/netfilter/nf_conntrack_core.c | 12 ------------
>> 2 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
>> index 90690e37a56f..8481819ff632 100644
>> --- a/include/net/netfilter/nf_conntrack.h
>> +++ b/include/net/netfilter/nf_conntrack.h
>> @@ -279,6 +279,18 @@ static inline bool nf_ct_should_gc(const struct nf_conn *ct)
>> !nf_ct_is_dying(ct);
>> }
>>
>> +#define DAY (86400 * HZ)
>> +
>> +/* Set an arbitrary timeout large enough not to ever expire, this save
>> + * us a check for the IPS_OFFLOAD_BIT from the packet path via
>> + * nf_ct_is_expired().
>> + */
>> +static inline void nf_ct_offload_timeout(struct nf_conn *ct)
>> +{
>> + if (nf_ct_expires(ct) < DAY / 2)
>> + ct->timeout = nfct_time_stamp + DAY;
>> +}
>> +
>> struct kernel_param;
>>
>
> For the record: I have renamed DAY to NF_CT_DAY to avoid a possible
> symbol name clash. No need to resend, I applied this small change
> before applying.
>
thanks
^ permalink raw reply
* [PATCH net-next] mptcp: use mptcp_for_each_subflow in mptcp_stream_accept
From: Geliang Tang @ 2020-08-03 13:00 UTC (permalink / raw)
To: Mat Martineau, Matthieu Baerts, David S. Miller, Jakub Kicinski
Cc: Geliang Tang, netdev, mptcp, linux-kernel
Use mptcp_for_each_subflow in mptcp_stream_accept instead of
open-coding.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
net/mptcp/protocol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index d3fe7296e1c9..400824eabf73 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2249,7 +2249,7 @@ static int mptcp_stream_accept(struct socket *sock, struct socket *newsock,
* This is needed so NOSPACE flag can be set from tcp stack.
*/
__mptcp_flush_join_list(msk);
- list_for_each_entry(subflow, &msk->conn_list, node) {
+ mptcp_for_each_subflow(msk, subflow) {
struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
if (!ssk->sk_socket)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
From: Andrew Lunn @ 2020-08-03 12:57 UTC (permalink / raw)
To: Madalin Bucur (OSS)
Cc: Russell King - ARM Linux admin, Vikas Singh, f.fainelli@gmail.com,
hkallweit1@gmail.com, netdev@vger.kernel.org,
Calvin Johnson (OSS), kuldip dwivedi, Vikas Singh
In-Reply-To: <AM6PR04MB3976284AEC94129D26300485EC4D0@AM6PR04MB3976.eurprd04.prod.outlook.com>
> I see you agree that there were and there will be many changes for a while,
> It's not a complaint, I know hot it works, it's just a decision based on
> required effort vs features offered vs user requirements. Lately it's been
> time consuming to try to fix things in this area.
So the conclusion to all this that you are unwilling to use the
correct API for this, which would be phylink, and the SFP code. So:
NACK
Andrew
^ permalink raw reply
* Re: [PATCH net-next RFC 00/13] Add devlink reload level option
From: Vasundhara Volam @ 2020-08-03 12:47 UTC (permalink / raw)
To: Moshe Shemesh
Cc: Jacob Keller, David S. Miller, Jiri Pirko, Netdev, open list
In-Reply-To: <7a9c315f-fa29-7bd5-31be-3748b8841b29@mellanox.com>
On Mon, Aug 3, 2020 at 5:47 PM Moshe Shemesh <moshe@mellanox.com> wrote:
>
>
> On 8/3/2020 1:24 PM, Vasundhara Volam wrote:
> > On Tue, Jul 28, 2020 at 10:13 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
> >>
> >>
> >> On 7/27/2020 10:25 PM, Vasundhara Volam wrote:
> >>> On Mon, Jul 27, 2020 at 4:36 PM Moshe Shemesh <moshe@mellanox.com> wrote:
> >>>> Introduce new option on devlink reload API to enable the user to select the
> >>>> reload level required. Complete support for all levels in mlx5.
> >>>> The following reload levels are supported:
> >>>> driver: Driver entities re-instantiation only.
> >>>> fw_reset: Firmware reset and driver entities re-instantiation.
> >>> The Name is a little confusing. I think it should be renamed to
> >>> fw_live_reset (in which both firmware and driver entities are
> >>> re-instantiated). For only fw_reset, the driver should not undergo
> >>> reset (it requires a driver reload for firmware to undergo reset).
> >>>
> >> So, I think the differentiation here is that "live_patch" doesn't reset
> >> anything.
> > This seems similar to flashing the firmware and does not reset anything.
>
>
> The live patch is activating fw change without reset.
>
> It is not suitable for any fw change but fw gaps which don't require reset.
>
> I can query the fw to check if the pending image change is suitable or
> require fw reset.
Okay.
>
> >>>> fw_live_patch: Firmware live patching only.
> >>> This level is not clear. Is this similar to flashing??
> >>>
> >>> Also I have a basic query. The reload command is split into
> >>> reload_up/reload_down handlers (Please correct me if this behaviour is
> >>> changed with this patchset). What if the vendor specific driver does
> >>> not support up/down and needs only a single handler to fire a firmware
> >>> reset or firmware live reset command?
> >> In the "reload_down" handler, they would trigger the appropriate reset,
> >> and quiesce anything that needs to be done. Then on reload up, it would
> >> restore and bring up anything quiesced in the first stage.
> > Yes, I got the "reload_down" and "reload_up". Similar to the device
> > "remove" and "re-probe" respectively.
> >
> > But our requirement is a similar "ethtool reset" command, where
> > ethtool calls a single callback in driver and driver just sends a
> > firmware command for doing the reset. Once firmware receives the
> > command, it will initiate the reset of driver and firmware entities
> > asynchronously.
>
>
> It is similar to mlx5 case here for fw_reset. The driver triggers the fw
> command to reset and all PFs drivers gets events to handle and do
> re-initialization. To fit it to the devlink reload_down and reload_up,
> I wait for the event handler to complete and it stops at driver unload
> to have the driver up by devlink reload_up. See patch 8 in this patchset.
>
Yes, I see reload_down is triggering the reset. In our driver, after
triggering the reset through a firmware command, reset is done in
another context as the driver initiates the reset only after receiving
an ASYNC event from the firmware.
Probably, we have to use reload_down() to send firmware command to
trigger reset and do nothing in reload_up. And returning from reload
does not mean that reset is complete as it is done in another context
and the driver notifies the health reporter once the reset is
complete. devlink framework may have to allow drivers to implement
reload_down only to look more clean or call reload_up only if the
driver notifies the devlink once reset is completed from another
context. Please suggest.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox