* Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
From: Andy Lutomirski @ 2019-02-22 19:55 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Steven Rostedt, Linus Torvalds, Masami Hiramatsu,
Linux List Kernel Mailing, Ingo Molnar, Andrew Morton, stable,
Changbin Du, Jann Horn, Kees Cook, Andy Lutomirski, daniel,
netdev, bpf
In-Reply-To: <20190222193456.5vqppubzrcx5wsul@ast-mbp.dhcp.thefacebook.com>
> On Feb 22, 2019, at 11:34 AM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
>> On Fri, Feb 22, 2019 at 02:30:26PM -0500, Steven Rostedt wrote:
>> On Fri, 22 Feb 2019 11:27:05 -0800
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>>
>>>> On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
>>>>
>>>> Then we should still probably fix up "__probe_kernel_read()" to not
>>>> allow user accesses. The easiest way to do that is actually likely to
>>>> use the "unsafe_get_user()" functions *without* doing a
>>>> uaccess_begin(), which will mean that modern CPU's will simply fault
>>>> on a kernel access to user space.
>>>
>>> On bpf side the bpf_probe_read() helper just calls probe_kernel_read()
>>> and users pass both user and kernel addresses into it and expect
>>> that the helper will actually try to read from that address.
>>>
>>> If __probe_kernel_read will suddenly start failing on all user addresses
>>> it will break the expectations.
>>> How do we solve it in bpf_probe_read?
>>> Call probe_kernel_read and if that fails call unsafe_get_user byte-by-byte
>>> in the loop?
>>> That's doable, but people already complain that bpf_probe_read() is slow
>>> and shows up in their perf report.
>>
>> We're changing kprobes to add a specific flag to say that we want to
>> differentiate between kernel or user reads. Can this be done with
>> bpf_probe_read()? If it's showing up in perf report, I doubt a single
>
> so you're saying you will break existing kprobe scripts?
> I don't think it's a good idea.
> It's not acceptable to break bpf_probe_read uapi.
>
If so, the uapi is wrong: a long-sized number does not reliably identify an address if you don’t separately know whether it’s a user or kernel address. s390x and 4G:4G x86_32 are the notable exceptions. I have lobbied for RISC-V and future x86_64 to join the crowd. I don’t know whether I’ll win this fight, but the uapi will probably have to change for at least s390x.
What to do about existing scripts is a different question.
^ permalink raw reply
* Re: [PATCH] Documentation: networking: switchdev: Update port parent ID section
From: David Miller @ 2019-02-22 19:58 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, idosch, jiri
In-Reply-To: <20190220225850.23333-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 20 Feb 2019 14:58:50 -0800
> Update the section about switchdev drivers having to implement a
> switchdev_port_attr_get() function to return
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
> commit bccb30254a4a ("net: Get rid of
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID").
>
> Fixes: bccb30254a4a ("net: Get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID")
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: Three questions about busy poll
From: Samudrala, Sridhar @ 2019-02-22 20:00 UTC (permalink / raw)
To: Cong Wang; +Cc: Alexander Duyck, Eric Dumazet, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpXa_ra5Gi3Wiv+JRwixArozLDKOHHAdBym_3k1CzPYuaw@mail.gmail.com>
On 2/15/2019 11:18 AM, Cong Wang wrote:
> On Thu, Feb 14, 2019 at 4:43 PM Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
>>
>> On 2/14/2019 12:15 PM, Cong Wang wrote:
>>
>> Hello,
>>
>> While looking into the busy polling in Linux kernel, three questions
>> come into my mind:
>>
>> 1. In the document[1], it claims sysctl.net.busy_poll depends on
>> either SO_BUSY_POLL or sysctl.net.busy_read. However, from the code in
>> ep_set_busy_poll_napi_id(), I don't see such a dependency. It simply
>> checks sysctl_net_busy_poll and sk->sk_napi_id, but sk->sk_napi_id is
>> always set as long as we enable CONFIG_NET_RX_BUSY_POLL. So what I am
>> missing here?
>>
>> epoll based busypoll is only based on global sysctl_net_busy_poll.
>> busy_poll value is used with poll()/select()/epoll and and busy_read is used
>> with socket recvmsg
> Right, I was confused by what the term "poll" refers to.
>
>
>> 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
>> sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
>> sysctl.net.busy_read.
>>
>>
>> Not sure if it is useful to make it a per socket option. I think it could
>> be a per poll/epoll fd option
>
> It is useful, however, from Willem's reply it looks like hard to push it
> down from epoll() interface to each socket.
>
>> 3. How is SO_INCOMING_NAPI_ID supposed to be used? I can't find any
>> useful documents online. Any example or more detailed doc?
>>
>>
>> A app can create one worker thread per device queue and a worker thread
>> for an incoming connection can be selected based on SO_INCOMING_NAPI_ID so that
>> all connections coming on a queue are processed by the same thread. This will
>> allow epoll from a thread to be associated with sockets that receive packets
>> from a single queue allowing busy polling.
>>
> This information is very useful. It also requires each thread pinning to each
> CPU/RX queue, right?
Thread pinning will not be required if XPS is setup to use xps-rxqs that
allows
configuring symmetric queues so that tx-queue is selected based on rx-queue.
See XPS using receive queues map in Documentation/networking/scaling.txt
>
> Anyway, I will add this information to socket.7 man page.
>
> Thanks!
^ permalink raw reply
* Re: INFO: task hung in rtnetlink_rcv_msg
From: Jakub Kicinski @ 2019-02-22 20:01 UTC (permalink / raw)
To: Joe Perches
Cc: syzbot, ast, christian, daniel, davem, dsahern, hawk, idosch,
john.fastabend, kafai, ktkhai, linux-kernel, netdev, petrm, roopa,
songliubraving, syzkaller-bugs, xdp-newbies, yhs
In-Reply-To: <000000000000c07a5805827e85d5@google.com>
Hi!
Seems like something funny is going on with get_maintainer.pl since XDP
entry got added. We seem to have been CCed on:
net: ns83820: code cleanup for ns83820_probe_phy()
veth: Fix -Wformat-truncation
INFO: task hung in rtnetlink_rcv_msg
I tried Florian's veth patch myself and it does indeed produce:
"David S. Miller" <davem@davemloft.net> (odd fixer:NETWORKING DRIVERS,commit_signer:9/15=60%)
Alexei Starovoitov <ast@kernel.org> (supporter:XDP (eXpress Data Path))
Daniel Borkmann <daniel@iogearbox.net> (supporter:XDP (eXpress Data Path),commit_signer:6/15=40%)
Jakub Kicinski <jakub.kicinski@netronome.com> (supporter:XDP (eXpress Data Path))
Jesper Dangaard Brouer <hawk@kernel.org> (supporter:XDP (eXpress Data Path))
John Fastabend <john.fastabend@gmail.com> (supporter:XDP (eXpress Data Path),commit_signer:2/15=13%)
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> (commit_signer:11/15=73%,authored:11/15=73%,added_lines:1027/1055=97%,removed_lines:180/195=92%)
David Ahern <dsahern@gmail.com> (commit_signer:2/15=13%,authored:1/15=7%)
Li RongQing <lirongqing@baidu.com> (authored:1/15=7%,removed_lines:14/195=7%)
Michael Walle <michael@walle.cc> (authored:1/15=7%)
"Gustavo A. R. Silva" <gustavo@embeddedor.com> (authored:1/15=7%)
netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
linux-kernel@vger.kernel.org (open list)
xdp-newbies@vger.kernel.org (open list:XDP (eXpress Data Path))
Even though it only touches:
drivers/net/veth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
And XDP entry is:
XDP (eXpress Data Path)
M: Alexei Starovoitov <ast@kernel.org>
M: Daniel Borkmann <daniel@iogearbox.net>
M: David S. Miller <davem@davemloft.net>
M: Jakub Kicinski <jakub.kicinski@netronome.com>
M: Jesper Dangaard Brouer <hawk@kernel.org>
M: John Fastabend <john.fastabend@gmail.com>
L: netdev@vger.kernel.org
L: xdp-newbies@vger.kernel.org
S: Supported
F: net/core/xdp.c
F: include/net/xdp.h
F: kernel/bpf/devmap.c
F: kernel/bpf/cpumap.c
F: include/trace/events/xdp.h
K: xdp
N: xdp
So no relation to drivers at all...
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] devlink: create a special NDO for getting the devlink instance
From: Florian Fainelli @ 2019-02-22 20:04 UTC (permalink / raw)
To: Jakub Kicinski, davem, jiri; +Cc: mkubecek, andrew, netdev, oss-drivers
In-Reply-To: <20190222195410.9494-4-jakub.kicinski@netronome.com>
On 2/22/19 11:54 AM, Jakub Kicinski wrote:
> Instead of iterating over all devlink ports add a NDO which
> will return the devlink instance from the driver.
>
> v2: add the netdev_to_devlink() helper (Michal)
>
> Suggested-by: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
[snip]
> - mutex_unlock(&devlink_mutex);
> + devlink = netdev_to_devlink(dev);
> + if (!devlink || !devlink->ops->info_get)
> + return;
AFAICT devlink_create() allows one to specify a NULL ops argument (not
that this makes sense), so probably need to add a check against
devlink->ops here as well, unless we want to change devlink_create() to
refuse a NULL ops pointer.
Other than that:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> +
> + mutex_lock(&devlink->lock);
> + __devlink_compat_running_version(devlink, buf, len);
> + mutex_unlock(&devlink->lock);
> }
>
> int devlink_compat_flash_update(struct net_device *dev, const char *file_name)
> {
> - struct devlink_port *devlink_port;
> struct devlink *devlink;
> + int ret;
>
> - mutex_lock(&devlink_mutex);
> - list_for_each_entry(devlink, &devlink_list, list) {
> - mutex_lock(&devlink->lock);
> - list_for_each_entry(devlink_port, &devlink->port_list, list) {
> - int ret = -EOPNOTSUPP;
> -
> - if (devlink_port->type != DEVLINK_PORT_TYPE_ETH ||
> - devlink_port->type_dev != dev)
> - continue;
> -
> - mutex_unlock(&devlink_mutex);
> - if (devlink->ops->flash_update)
> - ret = devlink->ops->flash_update(devlink,
> - file_name,
> - NULL, NULL);
> - mutex_unlock(&devlink->lock);
> - return ret;
> - }
> - mutex_unlock(&devlink->lock);
> - }
> - mutex_unlock(&devlink_mutex);
> + devlink = netdev_to_devlink(dev);
> + if (!devlink || !devlink->ops->flash_update)
> + return -EOPNOTSUPP;
>
And same here.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 1/5] net: devlink: turn devlink into a built-in
From: Florian Fainelli @ 2019-02-22 20:07 UTC (permalink / raw)
To: Jakub Kicinski, davem, jiri; +Cc: mkubecek, andrew, netdev, oss-drivers
In-Reply-To: <20190222195410.9494-2-jakub.kicinski@netronome.com>
On 2/22/19 11:54 AM, Jakub Kicinski wrote:
> Being able to build devlink as a module causes growing pains.
> First all drivers had to add a meta dependency to make sure
> they are not built in when devlink is built as a module. Now
> we are struggling to invoke ethtool compat code reliably.
>
> Make devlink code built-in, users can still not build it at
> all but the dynamically loadable module option is removed.
One use case I was potentially thinking about was that you have to load
devlink at some point to e.g.: recover your device from an initramfs,
and then you don't use devlink anymore so just you rmmod it and you have
switched to a different filesystem entirely (possibly on the network
that you just helped recover). That sounds like a corner case though so:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] ethtool: hold a reference to the netdevice around devlink compat
From: Florian Fainelli @ 2019-02-22 20:09 UTC (permalink / raw)
To: Jakub Kicinski, davem, jiri; +Cc: mkubecek, andrew, netdev, oss-drivers
In-Reply-To: <20190222195410.9494-3-jakub.kicinski@netronome.com>
On 2/22/19 11:54 AM, Jakub Kicinski wrote:
> When calling into devlink compat code make sure we have a reference
> on the netdevice on which the operation was invoked.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> net/core/ethtool.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 1320e8dce559..6832476dfcaf 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -805,11 +805,14 @@ static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
> if (ops->get_eeprom_len)
> info.eedump_len = ops->get_eeprom_len(dev);
>
> - rtnl_unlock();
> - if (!info.fw_version[0])
> + if (!info.fw_version[0]) {
> + dev_hold(dev);
> + rtnl_unlock();
> devlink_compat_running_version(dev, info.fw_version,
> sizeof(info.fw_version));
> - rtnl_lock();
> + rtnl_lock();
> + dev_put(dev);
> + }
Would it make sense to make the locking and reference holding implicit
within the compat versions of devlink_* because they use a net_device ->
devlink object manipulation as opposed to doing in the caller. We are
more or less guaranteed that the compatibility layer is used from within
ethtool.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] devlink: create a special NDO for getting the devlink instance
From: Jakub Kicinski @ 2019-02-22 20:09 UTC (permalink / raw)
To: Florian Fainelli; +Cc: davem, jiri, mkubecek, andrew, netdev, oss-drivers
In-Reply-To: <4ae4a622-f45f-36a4-2ff5-b0553a40dc22@gmail.com>
On Fri, 22 Feb 2019 12:04:07 -0800, Florian Fainelli wrote:
> On 2/22/19 11:54 AM, Jakub Kicinski wrote:
> > Instead of iterating over all devlink ports add a NDO which
> > will return the devlink instance from the driver.
> >
> > v2: add the netdev_to_devlink() helper (Michal)
> >
> > Suggested-by: Jiri Pirko <jiri@resnulli.us>
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > ---
> [snip]
>
> > - mutex_unlock(&devlink_mutex);
> > + devlink = netdev_to_devlink(dev);
> > + if (!devlink || !devlink->ops->info_get)
> > + return;
>
> AFAICT devlink_create() allows one to specify a NULL ops argument (not
> that this makes sense), so probably need to add a check against
> devlink->ops here as well, unless we want to change devlink_create() to
> refuse a NULL ops pointer.
Oh, you're right! devlink_nl_cmd_reload() seems to be missing that
check as well. Let me respin quickly.
> Other than that:
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
^ permalink raw reply
* [PATCH 0/3] Cover letter: Add support for high speed MAC in Cadence controller driver
From: Parshuram Thombare @ 2019-02-22 20:11 UTC (permalink / raw)
To: nicolas.ferre, davem, netdev, andrew, f.fainelli, hkallweit1,
linux-kernel, rafalc, piotrs, jank, pthombar
Hello !
This patch series contain changes to support high speed MAC and PCS
in Cadence ethernet controller driver.
Here is the list of patches.
[PATCH 1/3] net: ethernet: add support for PCS and 2.5G speed
This patch add support for PCS (for SGMII interface) and 2.5Gbps
MAC in Cadence ethernet controller driver.
[PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
This patch modify MDIO read/write functions to support
communication with C45 PHY in Cadence ethernet controller driver.
[PATCH 3/3] net: ethernet: add support for high speed mac and usxgmii pcs
This patch add support for (10G) high speed mac, usxgmii pcs
and usxgmii interface in Cadence ethernet controller driver.
Regards,
Parshuram Thombare
Parshuram Thombare (3):
net: ethernet: add support for PCS and 2.5G speed
net: ethernet: add c45 PHY support in MDIO read/write functions.
net: ethernet: add support for high speed mac and usxgmii pcs
drivers/net/ethernet/cadence/macb.h | 68 ++++++-
drivers/net/ethernet/cadence/macb_main.c | 309 +++++++++++++++++++++++++----
include/linux/phy.h | 3 +
3 files changed, 333 insertions(+), 47 deletions(-)
^ permalink raw reply
* [PATCH 1/3] net: ethernet: add support for PCS and 2.5G speed
From: Parshuram Thombare @ 2019-02-22 20:12 UTC (permalink / raw)
To: nicolas.ferre, davem, netdev, andrew, f.fainelli, hkallweit1,
linux-kernel, rafalc, piotrs, jank, pthombar
This patch add support for PCS (for SGMII interface) and 2.5Gbps MAC
in Cadence ethernet controller driver.
Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
---
drivers/net/ethernet/cadence/macb.h | 20 ++++
drivers/net/ethernet/cadence/macb_main.c | 154 +++++++++++++++++++++++-------
2 files changed, 140 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 9bbaad9..bed4ded 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -79,6 +79,7 @@
#define MACB_RBQPH 0x04D4
/* GEM register offsets. */
+#define GEM_NCR 0x0000 /* Network Control */
#define GEM_NCFGR 0x0004 /* Network Config */
#define GEM_USRIO 0x000c /* User IO */
#define GEM_DMACFG 0x0010 /* DMA Configuration */
@@ -273,6 +274,10 @@
#define MACB_IRXFCS_OFFSET 19
#define MACB_IRXFCS_SIZE 1
+/* GEM specific NCR bitfields. */
+#define GEM_TWO_PT_FIVE_GIG_OFFSET 29
+#define GEM_TWO_PT_FIVE_GIG_SIZE 1
+
/* GEM specific NCFGR bitfields. */
#define GEM_GBE_OFFSET 10 /* Gigabit mode enable */
#define GEM_GBE_SIZE 1
@@ -463,6 +468,8 @@
#define GEM_IRQCOR_SIZE 1
#define GEM_DBWDEF_OFFSET 25
#define GEM_DBWDEF_SIZE 3
+#define GEM_NO_PCS_OFFSET 0
+#define GEM_NO_PCS_SIZE 1
/* Bitfields in DCFG2. */
#define GEM_RX_PKT_BUFF_OFFSET 20
@@ -648,6 +655,19 @@
#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
#define MACB_CAPS_SG_DISABLED 0x40000000
#define MACB_CAPS_MACB_IS_GEM 0x80000000
+#define MACB_CAPS_PCS 0x01000000
+#define MACB_CAPS_TWO_PT_FIVE_GIG_SPEED 0x02000000
+
+#define MACB_GEM7010_IDNUM 0x009
+#define MACB_GEM7014_IDNUM 0x107
+#define MACB_GEM7014A_IDNUM 0x207
+#define MACB_GEM7016_IDNUM 0x10a
+#define MACB_GEM7017_IDNUM 0x00a
+#define MACB_GEM7017A_IDNUM 0x20a
+#define MACB_GEM7020_IDNUM 0x003
+#define MACB_GEM7021_IDNUM 0x00c
+#define MACB_GEM7021A_IDNUM 0x20c
+#define MACB_GEM7022_IDNUM 0x00b
/* LSO settings */
#define MACB_LSO_UFO_ENABLE 0x01
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index f2915f2..4f4f8e5 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -361,26 +361,50 @@ static int macb_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
* macb_set_tx_clk() - Set a clock to a new frequency
* @clk Pointer to the clock to change
* @rate New frequency in Hz
+ * @interafce Phy interface
* @dev Pointer to the struct net_device
*/
-static void macb_set_tx_clk(struct clk *clk, int speed, struct net_device *dev)
+static void macb_set_tx_clk(struct clk *clk, int speed,
+ phy_interface_t interface, struct net_device *dev)
{
long ferr, rate, rate_rounded;
if (!clk)
return;
- switch (speed) {
- case SPEED_10:
+ if (interface == PHY_INTERFACE_MODE_GMII ||
+ interface == PHY_INTERFACE_MODE_MII) {
+ switch (speed) {
+ case SPEED_10:
rate = 2500000;
break;
- case SPEED_100:
+ case SPEED_100:
rate = 25000000;
break;
- case SPEED_1000:
+ case SPEED_1000:
rate = 125000000;
break;
- default:
+ default:
+ return;
+ }
+ } else if (interface == PHY_INTERFACE_MODE_SGMII) {
+ switch (speed) {
+ case SPEED_10:
+ rate = 1250000;
+ break;
+ case SPEED_100:
+ rate = 12500000;
+ break;
+ case SPEED_1000:
+ rate = 125000000;
+ break;
+ case SPEED_2500:
+ rate = 312500000;
+ break;
+ default:
+ return;
+ }
+ } else {
return;
}
@@ -410,30 +434,49 @@ static void macb_handle_link_change(struct net_device *dev)
spin_lock_irqsave(&bp->lock, flags);
- if (phydev->link) {
- if ((bp->speed != phydev->speed) ||
- (bp->duplex != phydev->duplex)) {
- u32 reg;
-
- reg = macb_readl(bp, NCFGR);
- reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
- if (macb_is_gem(bp))
- reg &= ~GEM_BIT(GBE);
+ if (phydev->link && (bp->speed != phydev->speed ||
+ bp->duplex != phydev->duplex)) {
+ u32 reg;
- if (phydev->duplex)
- reg |= MACB_BIT(FD);
+ reg = macb_readl(bp, NCFGR);
+ reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
+ if (macb_is_gem(bp))
+ reg &= ~GEM_BIT(GBE);
+ if (phydev->duplex)
+ reg |= MACB_BIT(FD);
+ macb_or_gem_writel(bp, NCFGR, reg);
+
+ if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII &&
+ (phydev->speed == SPEED_1000 ||
+ phydev->speed == SPEED_2500)) {
+ if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED) {
+ reg = gem_readl(bp, NCR) &
+ ~GEM_BIT(TWO_PT_FIVE_GIG);
+ gem_writel(bp, NCR, reg);
+ }
+ gem_writel(bp, NCFGR, GEM_BIT(GBE) |
+ gem_readl(bp, NCFGR));
+ if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED &&
+ phydev->speed == SPEED_2500)
+ gem_writel(bp, NCR, gem_readl(bp, NCR) |
+ GEM_BIT(TWO_PT_FIVE_GIG));
+ } else if (phydev->speed == SPEED_1000) {
+ gem_writel(bp, NCFGR, GEM_BIT(GBE) |
+ gem_readl(bp, NCFGR));
+ } else {
+ if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ reg = gem_readl(bp, NCFGR);
+ reg &= ~(GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
+ gem_writel(bp, NCFGR, reg);
+ }
if (phydev->speed == SPEED_100)
- reg |= MACB_BIT(SPD);
- if (phydev->speed == SPEED_1000 &&
- bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
- reg |= GEM_BIT(GBE);
-
- macb_or_gem_writel(bp, NCFGR, reg);
-
- bp->speed = phydev->speed;
- bp->duplex = phydev->duplex;
- status_change = 1;
+ macb_writel(bp, NCFGR, MACB_BIT(SPD) |
+ macb_readl(bp, NCFGR));
}
+
+ bp->speed = phydev->speed;
+ bp->duplex = phydev->duplex;
+ status_change = 1;
}
if (phydev->link != bp->link) {
@@ -453,7 +496,8 @@ static void macb_handle_link_change(struct net_device *dev)
/* Update the TX clock rate if and only if the link is
* up and there has been a link change.
*/
- macb_set_tx_clk(bp->tx_clk, phydev->speed, dev);
+ macb_set_tx_clk(bp->tx_clk, phydev->speed,
+ bp->phy_interface, dev);
netif_carrier_on(dev);
netdev_info(dev, "link up (%d/%s)\n",
@@ -543,10 +587,16 @@ static int macb_mii_probe(struct net_device *dev)
}
/* mask with MAC supported features */
- if (macb_is_gem(bp) && bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
- phy_set_max_speed(phydev, SPEED_1000);
- else
- phy_set_max_speed(phydev, SPEED_100);
+ if (macb_is_gem(bp)) {
+ linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
+ if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
+ linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ phydev->supported);
+ } else {
+ linkmode_copy(phydev->supported, PHY_BASIC_FEATURES);
+ }
+
+ linkmode_copy(phydev->advertising, phydev->supported);
if (bp->caps & MACB_CAPS_NO_GIGABIT_HALF)
phy_remove_link_mode(phydev,
@@ -2217,8 +2267,6 @@ static void macb_init_hw(struct macb *bp)
macb_set_hwaddr(bp);
config = macb_mdc_clk_div(bp);
- if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII)
- config |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
config |= MACB_BF(RBOF, NET_IP_ALIGN); /* Make eth data aligned */
config |= MACB_BIT(PAE); /* PAuse Enable */
config |= MACB_BIT(DRFCS); /* Discard Rx FCS */
@@ -3255,6 +3303,23 @@ static void macb_configure_caps(struct macb *bp,
dcfg = gem_readl(bp, DCFG1);
if (GEM_BFEXT(IRQCOR, dcfg) == 0)
bp->caps |= MACB_CAPS_ISR_CLEAR_ON_WRITE;
+ if (GEM_BFEXT(NO_PCS, dcfg) == 0)
+ bp->caps |= MACB_CAPS_PCS;
+ switch (MACB_BFEXT(IDNUM, macb_readl(bp, MID))) {
+ case MACB_GEM7016_IDNUM:
+ case MACB_GEM7017_IDNUM:
+ case MACB_GEM7017A_IDNUM:
+ case MACB_GEM7020_IDNUM:
+ case MACB_GEM7021_IDNUM:
+ case MACB_GEM7021A_IDNUM:
+ case MACB_GEM7022_IDNUM:
+ if (bp->caps & MACB_CAPS_PCS)
+ bp->caps |= MACB_CAPS_TWO_PT_FIVE_GIG_SPEED;
+ break;
+
+ default:
+ break;
+ }
dcfg = gem_readl(bp, DCFG2);
if ((dcfg & (GEM_BIT(RX_PKT_BUFF) | GEM_BIT(TX_PKT_BUFF))) == 0)
bp->caps |= MACB_CAPS_FIFO_MODE;
@@ -4110,7 +4175,28 @@ static int macb_probe(struct platform_device *pdev)
else
bp->phy_interface = PHY_INTERFACE_MODE_MII;
} else {
+ switch (err) {
+ case PHY_INTERFACE_MODE_SGMII:
+ if (bp->caps & MACB_CAPS_PCS) {
+ bp->phy_interface = PHY_INTERFACE_MODE_SGMII;
+ break;
+ }
+ /* Fallthrough */
+
+ default:
+ if (macb_is_gem(bp))
+ err = PHY_INTERFACE_MODE_GMII;
+ else
+ err = PHY_INTERFACE_MODE_MII;
+ /* Fallthrough */
+
+ case PHY_INTERFACE_MODE_GMII:
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_MII:
+ case PHY_INTERFACE_MODE_RMII:
bp->phy_interface = err;
+ break;
+ }
}
/* IP specific init */
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
From: Parshuram Thombare @ 2019-02-22 20:12 UTC (permalink / raw)
To: nicolas.ferre, davem, netdev, andrew, f.fainelli, hkallweit1,
linux-kernel, rafalc, piotrs, jank, pthombar
This patch modify MDIO read/write functions to support
communication with C45 PHY in Cadence ethernet controller driver.
Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
---
drivers/net/ethernet/cadence/macb.h | 15 +++++--
drivers/net/ethernet/cadence/macb_main.c | 61 ++++++++++++++++++++++++-----
2 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index bed4ded..59c23e0 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -636,10 +636,17 @@
#define GEM_CLK_DIV96 5
/* Constants for MAN register */
-#define MACB_MAN_SOF 1
-#define MACB_MAN_WRITE 1
-#define MACB_MAN_READ 2
-#define MACB_MAN_CODE 2
+#define MACB_MAN_C22_SOF 1
+#define MACB_MAN_C22_WRITE 1
+#define MACB_MAN_C22_READ 2
+#define MACB_MAN_C22_CODE 2
+
+#define MACB_MAN_C45_SOF 0
+#define MACB_MAN_C45_ADDR 0
+#define MACB_MAN_C45_WRITE 1
+#define MACB_MAN_C45_POST_READ_INCR 2
+#define MACB_MAN_C45_READ 3
+#define MACB_MAN_C45_CODE 2
/* Capability mask bits */
#define MACB_CAPS_ISR_CLEAR_ON_WRITE 0x00000001
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 4f4f8e5..2494abf 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -323,11 +323,30 @@ static int macb_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
struct macb *bp = bus->priv;
int value;
- macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
- | MACB_BF(RW, MACB_MAN_READ)
- | MACB_BF(PHYA, mii_id)
- | MACB_BF(REGA, regnum)
- | MACB_BF(CODE, MACB_MAN_CODE)));
+ if (regnum & MII_ADDR_C45) {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_ADDR)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(DATA, regnum & 0xFFFF)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+
+ /* wait for end of transfer */
+ while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
+ cpu_relax();
+
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_READ)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+ } else {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C22_SOF)
+ | MACB_BF(RW, MACB_MAN_C22_READ)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, regnum)
+ | MACB_BF(CODE, MACB_MAN_C22_CODE)));
+ }
/* wait for end of transfer */
while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
@@ -343,12 +362,32 @@ static int macb_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
{
struct macb *bp = bus->priv;
- macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
- | MACB_BF(RW, MACB_MAN_WRITE)
- | MACB_BF(PHYA, mii_id)
- | MACB_BF(REGA, regnum)
- | MACB_BF(CODE, MACB_MAN_CODE)
- | MACB_BF(DATA, value)));
+ if (regnum & MII_ADDR_C45) {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_ADDR)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(DATA, regnum & 0xFFFF)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+
+ /* wait for end of transfer */
+ while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
+ cpu_relax();
+
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_WRITE)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)
+ | MACB_BF(DATA, value))); //Data
+ } else {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C22_SOF)
+ | MACB_BF(RW, MACB_MAN_C22_WRITE)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, regnum)
+ | MACB_BF(CODE, MACB_MAN_C22_CODE)
+ | MACB_BF(DATA, value)));
+ }
/* wait for end of transfer */
while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3] net: ethernet: add support for high speed mac and usxgmii pcs
From: Parshuram Thombare @ 2019-02-22 20:13 UTC (permalink / raw)
To: nicolas.ferre, davem, netdev, andrew, f.fainelli, hkallweit1,
linux-kernel, rafalc, piotrs, jank, pthombar
This patch add support for (10G) high speed mac, usxgmii pcs
and usxgmii interface in Cadence ethernet controller driver.
Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
---
drivers/net/ethernet/cadence/macb.h | 33 +++++++++
drivers/net/ethernet/cadence/macb_main.c | 110 ++++++++++++++++++++++++++++--
include/linux/phy.h | 3 +
3 files changed, 140 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 59c23e0..34df014 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -84,6 +84,7 @@
#define GEM_USRIO 0x000c /* User IO */
#define GEM_DMACFG 0x0010 /* DMA Configuration */
#define GEM_JML 0x0048 /* Jumbo Max Length */
+#define GEM_HS_MAC_CONFIG 0x0050 /* GEM high speed config */
#define GEM_HRB 0x0080 /* Hash Bottom */
#define GEM_HRT 0x0084 /* Hash Top */
#define GEM_SA1B 0x0088 /* Specific1 Bottom */
@@ -168,6 +169,9 @@
#define GEM_DCFG7 0x0298 /* Design Config 7 */
#define GEM_DCFG8 0x029C /* Design Config 8 */
#define GEM_DCFG10 0x02A4 /* Design Config 10 */
+#define GEM_DCFG12 0x02AC /* Design Config 12 */
+#define GEM_USX_CONTROL 0x0A80 /* USXGMII control register */
+#define GEM_USX_STATUS 0x0A88 /* USXGMII status register */
#define GEM_TXBDCTRL 0x04cc /* TX Buffer Descriptor control register */
#define GEM_RXBDCTRL 0x04d0 /* RX Buffer Descriptor control register */
@@ -275,6 +279,8 @@
#define MACB_IRXFCS_SIZE 1
/* GEM specific NCR bitfields. */
+#define GEM_ENABLE_HS_MAC_OFFSET 31
+#define GEM_ENABLE_HS_MAC_SIZE 1
#define GEM_TWO_PT_FIVE_GIG_OFFSET 29
#define GEM_TWO_PT_FIVE_GIG_SIZE 1
@@ -463,6 +469,10 @@
#define MACB_REV_OFFSET 0
#define MACB_REV_SIZE 16
+/* Bitfield in HS_MAC_CONFIG */
+#define GEM_HS_MAC_SPEED_OFFSET 0
+#define GEM_HS_MAC_SPEED_SIZE 3
+
/* Bitfields in DCFG1. */
#define GEM_IRQCOR_OFFSET 23
#define GEM_IRQCOR_SIZE 1
@@ -504,6 +514,28 @@
#define GEM_RXBD_RDBUFF_OFFSET 8
#define GEM_RXBD_RDBUFF_SIZE 4
+/* Bitfields in DCFG12. */
+#define GEM_HIGH_SPEED_OFFSET 26
+#define GEM_HIGH_SPEED_SIZE 1
+
+/* Bitfields in USX_CONTROL. */
+#define GEM_USX_CTRL_SPEED_OFFSET 14
+#define GEM_USX_CTRL_SPEED_SIZE 3
+#define GEM_SERDES_RATE_OFFSET 12
+#define GEM_SERDES_RATE_SIZE 2
+#define GEM_TX_EN_OFFSET 1
+#define GEM_TX_EN_SIZE 1
+#define GEM_SIGNAL_OK_OFFSET 0
+#define GEM_SIGNAL_OK_SIZE 1
+
+/* Bitfields in USX_STATUS. */
+#define GEM_USX_TX_FAULT_OFFSET 28
+#define GEM_USX_TX_FAULT_SIZE 1
+#define GEM_USX_RX_FAULT_OFFSET 27
+#define GEM_USX_RX_FAULT_SIZE 1
+#define GEM_USX_BLOCK_LOCK_OFFSET 0
+#define GEM_USX_BLOCK_LOCK_SIZE 1
+
/* Bitfields in TISUBN */
#define GEM_SUBNSINCR_OFFSET 0
#define GEM_SUBNSINCR_SIZE 16
@@ -664,6 +696,7 @@
#define MACB_CAPS_MACB_IS_GEM 0x80000000
#define MACB_CAPS_PCS 0x01000000
#define MACB_CAPS_TWO_PT_FIVE_GIG_SPEED 0x02000000
+#define MACB_CAPS_HIGH_SPEED 0x04000000
#define MACB_GEM7010_IDNUM 0x009
#define MACB_GEM7014_IDNUM 0x107
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 2494abf..0e0acf9 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -79,6 +79,21 @@
*/
#define MACB_HALT_TIMEOUT 1230
+enum {
+ HS_MAC_SPEED_100M,
+ HS_MAC_SPEED_1000M,
+ HS_MAC_SPEED_2500M,
+ HS_MAC_SPEED_5000M,
+ HS_MAC_SPEED_10000M,
+ HS_MAC_SPEED_25000M,
+};
+
+enum {
+ MACB_SERDES_RATE_5_PT_15625Gbps,
+ MACB_SERDES_RATE_10_PT_3125Gbps,
+ MACB_SERDES_RATE_25_PT_78125Gbps,
+};
+
/* DMA buffer descriptor might be different size
* depends on hardware configuration:
*
@@ -443,6 +458,20 @@ static void macb_set_tx_clk(struct clk *clk, int speed,
default:
return;
}
+ } else if (interface == PHY_INTERFACE_MODE_USXGMII) {
+ struct macb *bp = netdev_priv(dev);
+ u32 serdes_rate = GEM_BFEXT(SERDES_RATE,
+ gem_readl(bp, USX_CONTROL));
+ switch (serdes_rate) {
+ case MACB_SERDES_RATE_5_PT_15625Gbps:
+ rate = 78125000;
+ break;
+ case MACB_SERDES_RATE_10_PT_3125Gbps:
+ rate = 156250000;
+ break;
+ default:
+ return;
+ }
} else {
return;
}
@@ -475,7 +504,7 @@ static void macb_handle_link_change(struct net_device *dev)
if (phydev->link && (bp->speed != phydev->speed ||
bp->duplex != phydev->duplex)) {
- u32 reg;
+ u32 reg, speed;
reg = macb_readl(bp, NCFGR);
reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
@@ -485,7 +514,53 @@ static void macb_handle_link_change(struct net_device *dev)
reg |= MACB_BIT(FD);
macb_or_gem_writel(bp, NCFGR, reg);
- if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII &&
+ if ((bp->phy_interface == PHY_INTERFACE_MODE_USXGMII ||
+ bp->phy_interface == PHY_INTERFACE_MODE_XGMII) &&
+ phydev->speed >= SPEED_100) {
+ gem_writel(bp, NCR, gem_readl(bp, NCR) |
+ GEM_BIT(ENABLE_HS_MAC));
+ if (bp->phy_interface == PHY_INTERFACE_MODE_USXGMII) {
+ /* Setup USXGMII PCS */
+ reg = gem_readl(bp, USX_CONTROL);
+ reg = GEM_BFINS(SERDES_RATE,
+ MACB_SERDES_RATE_5_PT_15625Gbps,
+ reg);
+ gem_writel(bp, USX_CONTROL, reg |
+ GEM_BIT(TX_EN) |
+ GEM_BIT(SIGNAL_OK));
+ while (!GEM_BFEXT(USX_BLOCK_LOCK,
+ gem_readl(bp, USX_STATUS)))
+ cpu_relax();
+ }
+ switch (phydev->speed) {
+ case SPEED_10000:
+ speed = HS_MAC_SPEED_10000M;
+ break;
+
+ case SPEED_5000:
+ speed = HS_MAC_SPEED_5000M;
+ break;
+
+ case SPEED_2500:
+ speed = HS_MAC_SPEED_2500M;
+ break;
+
+ case SPEED_1000:
+ speed = HS_MAC_SPEED_1000M;
+ break;
+
+ default:
+ case SPEED_100:
+ speed = HS_MAC_SPEED_100M;
+ break;
+ }
+ gem_writel(bp, HS_MAC_CONFIG,
+ GEM_BFINS(HS_MAC_SPEED, speed,
+ gem_readl(bp, HS_MAC_CONFIG)));
+ gem_writel(bp, USX_CONTROL,
+ GEM_BFINS(USX_CTRL_SPEED, speed,
+ gem_readl(bp, USX_CONTROL)));
+ } else if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII &&
(phydev->speed == SPEED_1000 ||
phydev->speed == SPEED_2500)) {
if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED) {
@@ -627,10 +702,15 @@ static int macb_mii_probe(struct net_device *dev)
/* mask with MAC supported features */
if (macb_is_gem(bp)) {
- linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
- if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
- linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
- phydev->supported);
+ if (bp->caps & MACB_CAPS_HIGH_SPEED) {
+ linkmode_copy(phydev->supported, PHY_10GBIT_FEATURES);
+ } else {
+ u32 bitmask = ETHTOOL_LINK_MODE_2500baseT_Full_BIT;
+
+ linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
+ if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
+ linkmode_set_bit(bitmask, phydev->supported);
+ }
} else {
linkmode_copy(phydev->supported, PHY_BASIC_FEATURES);
}
@@ -3344,6 +3424,9 @@ static void macb_configure_caps(struct macb *bp,
bp->caps |= MACB_CAPS_ISR_CLEAR_ON_WRITE;
if (GEM_BFEXT(NO_PCS, dcfg) == 0)
bp->caps |= MACB_CAPS_PCS;
+ dcfg = gem_readl(bp, DCFG12);
+ if (GEM_BFEXT(HIGH_SPEED, dcfg) == 1)
+ bp->caps |= MACB_CAPS_HIGH_SPEED;
switch (MACB_BFEXT(IDNUM, macb_readl(bp, MID))) {
case MACB_GEM7016_IDNUM:
case MACB_GEM7017_IDNUM:
@@ -4215,6 +4298,21 @@ static int macb_probe(struct platform_device *pdev)
bp->phy_interface = PHY_INTERFACE_MODE_MII;
} else {
switch (err) {
+ case PHY_INTERFACE_MODE_USXGMII:
+ if ((bp->caps & MACB_CAPS_HIGH_SPEED) &&
+ (bp->caps & MACB_CAPS_PCS)) {
+ bp->phy_interface = PHY_INTERFACE_MODE_USXGMII;
+ break;
+ }
+ /* Fallthrough */
+
+ case PHY_INTERFACE_MODE_XGMII:
+ if (bp->caps & MACB_CAPS_HIGH_SPEED) {
+ bp->phy_interface = PHY_INTERFACE_MODE_XGMII;
+ break;
+ }
+ /* Fallthrough */
+
case PHY_INTERFACE_MODE_SGMII:
if (bp->caps & MACB_CAPS_PCS) {
bp->phy_interface = PHY_INTERFACE_MODE_SGMII;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8e9fc57..b627e30 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -94,6 +94,7 @@
PHY_INTERFACE_MODE_RTBI,
PHY_INTERFACE_MODE_SMII,
PHY_INTERFACE_MODE_XGMII,
+ PHY_INTERFACE_MODE_USXGMII,
PHY_INTERFACE_MODE_MOCA,
PHY_INTERFACE_MODE_QSGMII,
PHY_INTERFACE_MODE_TRGMII,
@@ -162,6 +163,8 @@ unsigned int phy_supported_speeds(struct phy_device *phy,
return "smii";
case PHY_INTERFACE_MODE_XGMII:
return "xgmii";
+ case PHY_INTERFACE_MODE_USXGMII:
+ return "usxgmii";
case PHY_INTERFACE_MODE_MOCA:
return "moca";
case PHY_INTERFACE_MODE_QSGMII:
--
1.7.1
^ permalink raw reply related
* RE: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv
From: Ertman, David M @ 2019-02-22 20:13 UTC (permalink / raw)
To: Jason Gunthorpe, Saleem, Shiraz
Cc: dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T, Patil, Kiran
In-Reply-To: <20190221193523.GO17500@ziepe.ca>
> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgg@ziepe.ca]
> Sent: Thursday, February 21, 2019 11:35 AM
> To: Saleem, Shiraz <shiraz.saleem@intel.com>
> Cc: dledford@redhat.com; davem@davemloft.net; linux-
> rdma@vger.kernel.org; netdev@vger.kernel.org; Ismail, Mustafa
> <mustafa.ismail@intel.com>; Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
> Patil, Kiran <kiran.patil@intel.com>; Ertman, David M
> <david.m.ertman@intel.com>
> Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct
> i40e_netdev_priv
>
> On Thu, Feb 21, 2019 at 02:19:33AM +0000, Saleem, Shiraz wrote:
> > >Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to
> > >struct i40e_netdev_priv
> > >
> > >On Fri, Feb 15, 2019 at 11:10:48AM -0600, Shiraz Saleem wrote:
> > >> Expose the register/unregister function pointers in the struct
> > >> i40e_netdev_priv which is accesible via the netdev_priv() interface
> > >> in the RDMA driver. On a netdev notification in the RDMA driver,
> > >> the appropriate LAN driver register/unregister functions are
> > >> invoked from the struct i40e_netdev_priv structure,
> > >
> > >Why? In later patches we get an entire device_add() based thing. Why
> > >do you need two things?
> > >
> > >The RDMA driver should bind to the thing that device_add created and
> > >from there reliably get the netdev. It should not listen to netdev notifiers for
> attachment.
> >
> > In the new IDC mechanism between ice<->irdma, the LAN driver setups up
> > the device for us and attaches it to a software bus via device_add() based
> mechanism.
> > However, RDMA driver binds to the device only when the LAN 'register'
> > function is called in irdma.
>
> That doesn't make sense. The PCI driver should always create the required
> struct device attachment point when attachment is becomes possible.
>
> > There is no ordering guarantee in which irdma, i40e and ice modules load.
> > The netdev notifier is for the case where the irdma loads before i40e
> > or ice.
>
> You are supposed to use the driver core to handle this ordering.
>
> The pci driver creates the attachment points in the correct order, when they
> are ready for use, and the driver core will automatically attach registered
> device drivers to the attachement points, no matter the module load loader.
>
> You will have a netdev and a rdma attachment point, sounds like the RDMA one
> is created once the netdev is happy.
>
> Maybe what you are missing is a struct device_driver?
>
> Jason
I am assuming that the term PCI driver is being used to mean the PCI
subsystem in the kernel. If this assumption is wrong, please disregard the next
paragraph, but the following points will still apply.
The bus that the irdma driver is registering with is a software (pseudo) bus
and not a hardware bus, and since this software bus is being defined by the LAN
driver, the bus does not exist until a LAN driver is loaded, up, and ready to receive
registration from the irdma peer. The PCI driver does not have anything to with this
bus, and has no ability to perform the described functions. The irdma driver cannot
register with the software bus unless it registers with the LAN driver that controls the
bus. The LAN driver's register function will call "driver_register(&drv->driver)" for the
registering irdma driver.
Since the irdma driver is a consolidated driver (supports both ice and i40e LAN
drivers), we cannot guarantee that a given LAN driver will load before the irdma
driver. Even if we use module dependencies to make irdma depend on (ice ||
i40e), we have to consider the situation where a machine will have both an ice
supported LAN device and an i40e supported LAN device in it. In this case, the
load order could be (e.g.) i40e -> irdma -> ice. The irdma driver can check all
present netdevs when it loads to find the one that has the correct function
pointers in it, but it will have no way of knowing that a new software bus was
created by the second LAN driver to load.
This is why irdma is listening for netdev notifiers, so that whenever a new netdev
appears from a LAN driver loading after irdma, the irdma driver can evaluate
whether the new netdev was created by a LAN driver supported by irdma driver.
If I have misunderstood your concerns, I apologize and look forward to clarification.
Thanks,
-Dave Ertman
^ permalink raw reply
* [PATCH] MIPS: lantiq: Remove separate GPHY Firmware loader
From: Hauke Mehrtens @ 2019-02-22 20:13 UTC (permalink / raw)
To: paul.burton
Cc: linux-mips, devicetree, john, martin.blumenstingl, netdev,
Hauke Mehrtens
The separate GPHY Firmware loader driver is not used any more, the GPHY
firmware is now loaded by the GSWIP switch driver which also makes use
of the GPHY.
Remove the old unused GPHY firmware loader driver.
The GPHY firmware is useless without an Ethernet and switch driver, it
should not harm if loading this does not work for system using an old
device tree.
I am not aware of any vendor separating the device tree from the kernel
binary, it should be ok to remove this.
The code and the functionality form this separate GPHY firmware loader
was added to the gswip driver in commit 14fceff4771e ("net: dsa: Add
Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
This should go through the MIPS tree, but any other tree should also be
fine, I am not expecting any merge conflicts.
.../bindings/mips/lantiq/rcu-gphy.txt | 36 ---
.../devicetree/bindings/mips/lantiq/rcu.txt | 18 --
arch/mips/configs/xway_defconfig | 1 -
arch/mips/lantiq/Kconfig | 4 -
drivers/soc/lantiq/Makefile | 1 -
drivers/soc/lantiq/gphy.c | 224 ------------------
6 files changed, 284 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
delete mode 100644 drivers/soc/lantiq/gphy.c
diff --git a/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt b/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
deleted file mode 100644
index a0c19bd1ce66..000000000000
--- a/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Lantiq XWAY SoC GPHY binding
-============================
-
-This binding describes a software-defined ethernet PHY, provided by the RCU
-module on newer Lantiq XWAY SoCs (xRX200 and newer).
-
--------------------------------------------------------------------------------
-Required properties:
-- compatible : Should be one of
- "lantiq,xrx200a1x-gphy"
- "lantiq,xrx200a2x-gphy"
- "lantiq,xrx300-gphy"
- "lantiq,xrx330-gphy"
-- reg : Addrress of the GPHY FW load address register
-- resets : Must reference the RCU GPHY reset bit
-- reset-names : One entry, value must be "gphy" or optional "gphy2"
-- clocks : A reference to the (PMU) GPHY clock gate
-
-Optional properties:
-- lantiq,gphy-mode : GPHY_MODE_GE (default) or GPHY_MODE_FE as defined in
- <dt-bindings/mips/lantiq_xway_gphy.h>
-
-
--------------------------------------------------------------------------------
-Example for the GPHys on the xRX200 SoCs:
-
-#include <dt-bindings/mips/lantiq_rcu_gphy.h>
- gphy0: gphy@20 {
- compatible = "lantiq,xrx200a2x-gphy";
- reg = <0x20 0x4>;
-
- resets = <&reset0 31 30>, <&reset1 7 7>;
- reset-names = "gphy", "gphy2";
- clocks = <&pmu0 XRX200_PMU_GATE_GPHY>;
- lantiq,gphy-mode = <GPHY_MODE_GE>;
- };
diff --git a/Documentation/devicetree/bindings/mips/lantiq/rcu.txt b/Documentation/devicetree/bindings/mips/lantiq/rcu.txt
index 7f0822b4beae..58d51f480c9e 100644
--- a/Documentation/devicetree/bindings/mips/lantiq/rcu.txt
+++ b/Documentation/devicetree/bindings/mips/lantiq/rcu.txt
@@ -26,24 +26,6 @@ Example of the RCU bindings on a xRX200 SoC:
ranges = <0x0 0x203000 0x100>;
big-endian;
- gphy0: gphy@20 {
- compatible = "lantiq,xrx200a2x-gphy";
- reg = <0x20 0x4>;
-
- resets = <&reset0 31 30>, <&reset1 7 7>;
- reset-names = "gphy", "gphy2";
- lantiq,gphy-mode = <GPHY_MODE_GE>;
- };
-
- gphy1: gphy@68 {
- compatible = "lantiq,xrx200a2x-gphy";
- reg = <0x68 0x4>;
-
- resets = <&reset0 29 28>, <&reset1 6 6>;
- reset-names = "gphy", "gphy2";
- lantiq,gphy-mode = <GPHY_MODE_GE>;
- };
-
reset0: reset-controller@10 {
compatible = "lantiq,xrx200-reset";
reg = <0x10 4>, <0x14 4>;
diff --git a/arch/mips/configs/xway_defconfig b/arch/mips/configs/xway_defconfig
index c3cac29e8414..2bb02ea9fb4e 100644
--- a/arch/mips/configs/xway_defconfig
+++ b/arch/mips/configs/xway_defconfig
@@ -13,7 +13,6 @@ CONFIG_EMBEDDED=y
# CONFIG_COMPAT_BRK is not set
CONFIG_LANTIQ=y
CONFIG_PCI_LANTIQ=y
-CONFIG_XRX200_PHY_FW=y
CONFIG_CPU_MIPS32_R2=y
CONFIG_MIPS_VPE_LOADER=y
CONFIG_NR_CPUS=2
diff --git a/arch/mips/lantiq/Kconfig b/arch/mips/lantiq/Kconfig
index 188de95d6dbd..6c6802e482c9 100644
--- a/arch/mips/lantiq/Kconfig
+++ b/arch/mips/lantiq/Kconfig
@@ -52,8 +52,4 @@ config PCI_LANTIQ
bool "PCI Support"
depends on SOC_XWAY && PCI
-config XRX200_PHY_FW
- bool "XRX200 PHY firmware loader"
- depends on SOC_XWAY
-
endif
diff --git a/drivers/soc/lantiq/Makefile b/drivers/soc/lantiq/Makefile
index be9e866d53e5..35aa86bd1023 100644
--- a/drivers/soc/lantiq/Makefile
+++ b/drivers/soc/lantiq/Makefile
@@ -1,2 +1 @@
obj-y += fpi-bus.o
-obj-$(CONFIG_XRX200_PHY_FW) += gphy.o
diff --git a/drivers/soc/lantiq/gphy.c b/drivers/soc/lantiq/gphy.c
deleted file mode 100644
index feeb17cebc25..000000000000
--- a/drivers/soc/lantiq/gphy.c
+++ /dev/null
@@ -1,224 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published
- * by the Free Software Foundation.
- *
- * Copyright (C) 2012 John Crispin <blogic@phrozen.org>
- * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
- * Copyright (C) 2017 Hauke Mehrtens <hauke@hauke-m.de>
- */
-
-#include <linux/clk.h>
-#include <linux/delay.h>
-#include <linux/dma-mapping.h>
-#include <linux/firmware.h>
-#include <linux/mfd/syscon.h>
-#include <linux/module.h>
-#include <linux/reboot.h>
-#include <linux/regmap.h>
-#include <linux/reset.h>
-#include <linux/of_device.h>
-#include <linux/of_platform.h>
-#include <linux/property.h>
-#include <dt-bindings/mips/lantiq_rcu_gphy.h>
-
-#include <lantiq_soc.h>
-
-#define XRX200_GPHY_FW_ALIGN (16 * 1024)
-
-struct xway_gphy_priv {
- struct clk *gphy_clk_gate;
- struct reset_control *gphy_reset;
- struct reset_control *gphy_reset2;
- void __iomem *membase;
- char *fw_name;
-};
-
-struct xway_gphy_match_data {
- char *fe_firmware_name;
- char *ge_firmware_name;
-};
-
-static const struct xway_gphy_match_data xrx200a1x_gphy_data = {
- .fe_firmware_name = "lantiq/xrx200_phy22f_a14.bin",
- .ge_firmware_name = "lantiq/xrx200_phy11g_a14.bin",
-};
-
-static const struct xway_gphy_match_data xrx200a2x_gphy_data = {
- .fe_firmware_name = "lantiq/xrx200_phy22f_a22.bin",
- .ge_firmware_name = "lantiq/xrx200_phy11g_a22.bin",
-};
-
-static const struct xway_gphy_match_data xrx300_gphy_data = {
- .fe_firmware_name = "lantiq/xrx300_phy22f_a21.bin",
- .ge_firmware_name = "lantiq/xrx300_phy11g_a21.bin",
-};
-
-static const struct of_device_id xway_gphy_match[] = {
- { .compatible = "lantiq,xrx200a1x-gphy", .data = &xrx200a1x_gphy_data },
- { .compatible = "lantiq,xrx200a2x-gphy", .data = &xrx200a2x_gphy_data },
- { .compatible = "lantiq,xrx300-gphy", .data = &xrx300_gphy_data },
- { .compatible = "lantiq,xrx330-gphy", .data = &xrx300_gphy_data },
- {},
-};
-MODULE_DEVICE_TABLE(of, xway_gphy_match);
-
-static int xway_gphy_load(struct device *dev, struct xway_gphy_priv *priv,
- dma_addr_t *dev_addr)
-{
- const struct firmware *fw;
- void *fw_addr;
- dma_addr_t dma_addr;
- size_t size;
- int ret;
-
- ret = request_firmware(&fw, priv->fw_name, dev);
- if (ret) {
- dev_err(dev, "failed to load firmware: %s, error: %i\n",
- priv->fw_name, ret);
- return ret;
- }
-
- /*
- * GPHY cores need the firmware code in a persistent and contiguous
- * memory area with a 16 kB boundary aligned start address.
- */
- size = fw->size + XRX200_GPHY_FW_ALIGN;
-
- fw_addr = dmam_alloc_coherent(dev, size, &dma_addr, GFP_KERNEL);
- if (fw_addr) {
- fw_addr = PTR_ALIGN(fw_addr, XRX200_GPHY_FW_ALIGN);
- *dev_addr = ALIGN(dma_addr, XRX200_GPHY_FW_ALIGN);
- memcpy(fw_addr, fw->data, fw->size);
- } else {
- dev_err(dev, "failed to alloc firmware memory\n");
- ret = -ENOMEM;
- }
-
- release_firmware(fw);
-
- return ret;
-}
-
-static int xway_gphy_of_probe(struct platform_device *pdev,
- struct xway_gphy_priv *priv)
-{
- struct device *dev = &pdev->dev;
- const struct xway_gphy_match_data *gphy_fw_name_cfg;
- u32 gphy_mode;
- int ret;
- struct resource *res_gphy;
-
- gphy_fw_name_cfg = of_device_get_match_data(dev);
-
- priv->gphy_clk_gate = devm_clk_get(dev, NULL);
- if (IS_ERR(priv->gphy_clk_gate)) {
- dev_err(dev, "Failed to lookup gate clock\n");
- return PTR_ERR(priv->gphy_clk_gate);
- }
-
- res_gphy = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->membase = devm_ioremap_resource(dev, res_gphy);
- if (IS_ERR(priv->membase))
- return PTR_ERR(priv->membase);
-
- priv->gphy_reset = devm_reset_control_get(dev, "gphy");
- if (IS_ERR(priv->gphy_reset)) {
- if (PTR_ERR(priv->gphy_reset) != -EPROBE_DEFER)
- dev_err(dev, "Failed to lookup gphy reset\n");
- return PTR_ERR(priv->gphy_reset);
- }
-
- priv->gphy_reset2 = devm_reset_control_get_optional(dev, "gphy2");
- if (IS_ERR(priv->gphy_reset2))
- return PTR_ERR(priv->gphy_reset2);
-
- ret = device_property_read_u32(dev, "lantiq,gphy-mode", &gphy_mode);
- /* Default to GE mode */
- if (ret)
- gphy_mode = GPHY_MODE_GE;
-
- switch (gphy_mode) {
- case GPHY_MODE_FE:
- priv->fw_name = gphy_fw_name_cfg->fe_firmware_name;
- break;
- case GPHY_MODE_GE:
- priv->fw_name = gphy_fw_name_cfg->ge_firmware_name;
- break;
- default:
- dev_err(dev, "Unknown GPHY mode %d\n", gphy_mode);
- return -EINVAL;
- }
-
- return 0;
-}
-
-static int xway_gphy_probe(struct platform_device *pdev)
-{
- struct device *dev = &pdev->dev;
- struct xway_gphy_priv *priv;
- dma_addr_t fw_addr = 0;
- int ret;
-
- priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- ret = xway_gphy_of_probe(pdev, priv);
- if (ret)
- return ret;
-
- ret = clk_prepare_enable(priv->gphy_clk_gate);
- if (ret)
- return ret;
-
- ret = xway_gphy_load(dev, priv, &fw_addr);
- if (ret) {
- clk_disable_unprepare(priv->gphy_clk_gate);
- return ret;
- }
-
- reset_control_assert(priv->gphy_reset);
- reset_control_assert(priv->gphy_reset2);
-
- iowrite32be(fw_addr, priv->membase);
-
- reset_control_deassert(priv->gphy_reset);
- reset_control_deassert(priv->gphy_reset2);
-
- platform_set_drvdata(pdev, priv);
-
- return ret;
-}
-
-static int xway_gphy_remove(struct platform_device *pdev)
-{
- struct xway_gphy_priv *priv = platform_get_drvdata(pdev);
-
- iowrite32be(0, priv->membase);
-
- clk_disable_unprepare(priv->gphy_clk_gate);
-
- return 0;
-}
-
-static struct platform_driver xway_gphy_driver = {
- .probe = xway_gphy_probe,
- .remove = xway_gphy_remove,
- .driver = {
- .name = "xway-rcu-gphy",
- .of_match_table = xway_gphy_match,
- },
-};
-
-module_platform_driver(xway_gphy_driver);
-
-MODULE_FIRMWARE("lantiq/xrx300_phy11g_a21.bin");
-MODULE_FIRMWARE("lantiq/xrx300_phy22f_a21.bin");
-MODULE_FIRMWARE("lantiq/xrx200_phy11g_a14.bin");
-MODULE_FIRMWARE("lantiq/xrx200_phy11g_a22.bin");
-MODULE_FIRMWARE("lantiq/xrx200_phy22f_a14.bin");
-MODULE_FIRMWARE("lantiq/xrx200_phy22f_a22.bin");
-MODULE_AUTHOR("Martin Blumenstingl <martin.blumenstingl@googlemail.com>");
-MODULE_DESCRIPTION("Lantiq XWAY GPHY Firmware Loader");
-MODULE_LICENSE("GPL");
--
2.20.1
^ permalink raw reply related
* Re: INFO: task hung in rtnetlink_rcv_msg
From: Joe Perches @ 2019-02-22 20:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: syzbot, ast, christian, daniel, davem, dsahern, hawk, idosch,
john.fastabend, kafai, ktkhai, linux-kernel, netdev, petrm, roopa,
songliubraving, syzkaller-bugs, xdp-newbies, yhs
In-Reply-To: <20190222120129.1f2f1c17@cakuba.netronome.com>
On Fri, 2019-02-22 at 12:01 -0800, Jakub Kicinski wrote:
> Hi!
>
> Seems like something funny is going on with get_maintainer.pl since XDP
> entry got added. We seem to have been CCed on:
I suggest removing the MAINTAINERS line with
K: xdp
as xdp is a pretty generic file/patch content
regex match for the K: type
$ git grep --name-only xdp | wc -l
236
Rather more files than desired.
The N: match is dubious too.
It's generally better to have specific lists of
maintained file patterns rather than using the
K: and N: pattern matches.
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d7ad97b235ec..aa703e2cb882 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16970,7 +16970,6 @@ F: include/net/xdp.h
F: kernel/bpf/devmap.c
F: kernel/bpf/cpumap.c
F: include/trace/events/xdp.h
-K: xdp
N: xdp
XDP SOCKETS (AF_XDP)
^ permalink raw reply related
* Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv
From: Jason Gunthorpe @ 2019-02-22 20:23 UTC (permalink / raw)
To: Ertman, David M
Cc: Saleem, Shiraz, dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T, Patil, Kiran
In-Reply-To: <2B0E3F215D1AB84DA946C8BEE234CCC97B11DF23@ORSMSX101.amr.corp.intel.com>
On Fri, Feb 22, 2019 at 08:13:58PM +0000, Ertman, David M wrote:
> > From: Jason Gunthorpe [mailto:jgg@ziepe.ca]
> > Sent: Thursday, February 21, 2019 11:35 AM
> > To: Saleem, Shiraz <shiraz.saleem@intel.com>
> > Cc: dledford@redhat.com; davem@davemloft.net; linux-
> > rdma@vger.kernel.org; netdev@vger.kernel.org; Ismail, Mustafa
> > <mustafa.ismail@intel.com>; Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
> > Patil, Kiran <kiran.patil@intel.com>; Ertman, David M
> > <david.m.ertman@intel.com>
> > Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct
> > i40e_netdev_priv
> >
> > On Thu, Feb 21, 2019 at 02:19:33AM +0000, Saleem, Shiraz wrote:
> > > >Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to
> > > >struct i40e_netdev_priv
> > > >
> > > >On Fri, Feb 15, 2019 at 11:10:48AM -0600, Shiraz Saleem wrote:
> > > >> Expose the register/unregister function pointers in the struct
> > > >> i40e_netdev_priv which is accesible via the netdev_priv() interface
> > > >> in the RDMA driver. On a netdev notification in the RDMA driver,
> > > >> the appropriate LAN driver register/unregister functions are
> > > >> invoked from the struct i40e_netdev_priv structure,
> > > >
> > > >Why? In later patches we get an entire device_add() based thing. Why
> > > >do you need two things?
> > > >
> > > >The RDMA driver should bind to the thing that device_add created and
> > > >from there reliably get the netdev. It should not listen to netdev notifiers for
> > attachment.
> > >
> > > In the new IDC mechanism between ice<->irdma, the LAN driver setups up
> > > the device for us and attaches it to a software bus via device_add() based
> > mechanism.
> > > However, RDMA driver binds to the device only when the LAN 'register'
> > > function is called in irdma.
> >
> > That doesn't make sense. The PCI driver should always create the required
> > struct device attachment point when attachment is becomes possible.
> >
> > > There is no ordering guarantee in which irdma, i40e and ice modules load.
> > > The netdev notifier is for the case where the irdma loads before i40e
> > > or ice.
> >
> > You are supposed to use the driver core to handle this ordering.
> >
> > The pci driver creates the attachment points in the correct order, when they
> > are ready for use, and the driver core will automatically attach registered
> > device drivers to the attachement points, no matter the module load loader.
> >
> > You will have a netdev and a rdma attachment point, sounds like the RDMA one
> > is created once the netdev is happy.
> >
> > Maybe what you are missing is a struct device_driver?
> >
> > Jason
>
> I am assuming that the term PCI driver is being used to mean the PCI
> subsystem in the kernel. If this assumption is wrong, please disregard the next
> paragraph, but the following points will still apply.
No, I mean the driver that has the struct pci_driver for the PCI
function. Maybe that is the LAN driver for this case.
> bus, and has no ability to perform the described functions. The
> irdma driver cannot register with the software bus unless it
> registers with the LAN driver that controls the bus. The LAN
> driver's register function will call "driver_register(&drv->driver)"
> for the registering irdma driver.
That isn't how to use the driver core.
> Since the irdma driver is a consolidated driver (supports both ice and i40e LAN
> drivers), we cannot guarantee that a given LAN driver will load before the irdma
> driver. Even if we use module dependencies to make irdma depend on (ice ||
> i40e), we have to consider the situation where a machine will have both an ice
> supported LAN device and an i40e supported LAN device in it. In this case, the
> load order could be (e.g.) i40e -> irdma -> ice. The irdma driver can check all
> present netdevs when it loads to find the one that has the correct function
> pointers in it, but it will have no way of knowing that a new software bus was
> created by the second LAN driver to load.
This is why you use the driver core to manage driver binding.
> This is why irdma is listening for netdev notifiers, so that whenever a new netdev
> appears from a LAN driver loading after irdma, the irdma driver can evaluate
> whether the new netdev was created by a LAN driver supported by irdma driver.
Register a device driver to the driver core and wait for the driver
core to call that driver's probe method.
Jason
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Dominique Martinet @ 2019-02-22 20:27 UTC (permalink / raw)
To: Tom Herbert
Cc: Tom Herbert, David Miller, Doron Roberts-Kedes, Dave Watson,
Linux Kernel Network Developers, LKML
In-Reply-To: <CALx6S36o3JVHh3UtOsfXNrosXK0NCZo703gfzfJPgJvZK9brOA@mail.gmail.com>
Tom Herbert wrote on Fri, Feb 22, 2019:
> > > So basically it sounds like you're interested in supporting TCP
> > > connections that are half closed. I believe that the error in half
> > > closed is EPIPE, so if the TCP socket returns that it can be ignored
> > > and the socket can continue being attached and used to send data.
> >
> > Did you mean 'can continue being attached and used to receive data'?
>
> No, I meant shutdown on receive side when FIN is receved. TX is still
> allowed to drain an queued bytes. To support shutdown on the TX side
> would require additional logic since we need to effectively detach the
> transmit path but retain the receive path. I'm not sure this is a
> compelling use case to support.
Hm, it must be a matter of how we see thing but from what I understand
it's exactly the other way around. The remote closed the connection, so
trying to send anything would just yield a RST, so TX doesn't make
sense.
On the other hand, anything that had been sent by the remote before the
FIN and is on the local side's memory should still be receivable.
When you think about it as a TCP stream it's really weird: data coming,
data coming, data coming, FIN received.
But in the networking stack that received FIN short-circuits all the
data that was left around and immediately raises an EPIPE error.
I don't see what makes this FIN packet so great that it should be
processed before the data; we should only see that EPIPE when we're
done reading the data before it or trying to send something.
I'll check tomorrow/next week but I'm pretty sure the packets before
that have been ack'd at a tcp level as well, so losing them in the
application level is really unexpected.
> > I can confirm getsockopt with SO_ERROR gets me EPIPE, but I don't see
> > how to efficiently ignore EPIPE until POLLIN gets unset -- polling on
> > both the csock and kcm socket will do many needless wakeups on only the
> > csock from what I can see, so I'd need some holdoff timer or something.
> > I guess it's possible though.
>
> We might need to clear the error somehow. May a read of zero bytes?
Can try.
> > After a bit more debugging, this part works (__strp_recv() is called
> > again); but the next packet that is treated properly is rejected because
> > by the time __strp_recv() was called again a new skb was read and the
> > length isn't large enough to go all the way into the new packet, so this
> > test fails:
> > } else if (len <= (ssize_t)head->len -
> > skb->len - stm->strp.offset) {
> > /* Length must be into new skb (and also
> > * greater than zero)
> > */
> > STRP_STATS_INCR(strp->stats.bad_hdr_len);
> > strp_parser_err(strp, -EPROTO, desc);
> >
> > So I need to figure a way to say "call this function again without
> > reading more data" somehow, or make this check more lax e.g. accept any
> > len > 0 after a retry maybe...
> > Removing that branch altogether seems to work at least but I'm not sure
> > we'd want to?
>
> I like the check since it's conservative and covers the normal case.
> Maybe just need some more logic?
I can add a "retrying" state and not fail here if we ewre retrying for
whatever reason perhaps...
But I'm starting to wonder how this would work if my client didn't keep
on sending data, I'll try to fail on the last client's packet and see
how __strp_recv is called again through the timer, with the same skb
perhaps?
--
Dominique
^ permalink raw reply
* [PATCH net-next 0/2] net: switchdev.h inclusion removal
From: Florian Fainelli @ 2019-02-22 20:31 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli
Hi David,
This targets a few drivers that no longer to have net/switchdev.h
included.
Florian Fainelli (2):
nfp: Remove switchdev.h inclusion
net: Remove switchdev.h inclusion from team/bond/vlan
drivers/net/bonding/bond_main.c | 1 -
drivers/net/ethernet/netronome/nfp/nfp_port.c | 1 -
drivers/net/team/team.c | 1 -
net/8021q/vlan_dev.c | 1 -
4 files changed, 4 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next 1/2] nfp: Remove switchdev.h inclusion
From: Florian Fainelli @ 2019-02-22 20:31 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Jakub Kicinski, David S. Miller,
Dirk van der Merwe, Jiri Pirko,
open list:NETRONOME ETHERNET DRIVERS, open list
In-Reply-To: <20190222203134.19508-1-f.fainelli@gmail.com>
This is no longer necessary after a5084bb71fa4 ("nfp: Implement
ndo_get_port_parent_id()")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/netronome/nfp/nfp_port.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_port.c b/drivers/net/ethernet/netronome/nfp/nfp_port.c
index 7e90880fa46b..93c5bfc0510b 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_port.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_port.c
@@ -3,7 +3,6 @@
#include <linux/lockdep.h>
#include <linux/netdevice.h>
-#include <net/switchdev.h>
#include "nfpcore/nfp_cpp.h"
#include "nfpcore/nfp_nsp.h"
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: Remove switchdev.h inclusion from team/bond/vlan
From: Florian Fainelli @ 2019-02-22 20:31 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Jay Vosburgh, Veaceslav Falico, Andy Gospodarek,
David S. Miller, Jiri Pirko, Hangbin Liu, Richard Cochran,
Davide Caratti, Debabrata Banerjee, Sun Lianwen, open list
In-Reply-To: <20190222203134.19508-1-f.fainelli@gmail.com>
This is no longer necessary after eca59f691566 ("net: Remove support for bridge bypass ndos from stacked devices")
Suggested-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/bonding/bond_main.c | 1 -
drivers/net/team/team.c | 1 -
net/8021q/vlan_dev.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 485462d3087f..a044a8032a0f 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -77,7 +77,6 @@
#include <net/pkt_sched.h>
#include <linux/rculist.h>
#include <net/flow_dissector.h>
-#include <net/switchdev.h>
#include <net/bonding.h>
#include <net/bond_3ad.h>
#include <net/bond_alb.h>
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 958f1cf67282..3ff23a993668 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -28,7 +28,6 @@
#include <net/genetlink.h>
#include <net/netlink.h>
#include <net/sch_generic.h>
-#include <net/switchdev.h>
#include <generated/utsrelease.h>
#include <linux/if_team.h>
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index b2d9c8f27cd7..15293c2a5dd8 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -31,7 +31,6 @@
#include <linux/ethtool.h>
#include <linux/phy.h>
#include <net/arp.h>
-#include <net/switchdev.h>
#include "vlan.h"
#include "vlanproc.h"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 1/7] net: phy: marvell10g: Use get_features to get the PHY abilities
From: Maxime Chevallier @ 2019-02-22 20:45 UTC (permalink / raw)
To: Heiner Kallweit
Cc: davem, netdev, linux-kernel, Andrew Lunn, Florian Fainelli,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <a69da540-fe5c-e9a7-d848-2f2c61011f21@gmail.com>
On Fri, 22 Feb 2019 19:42:29 +0100
Heiner Kallweit <hkallweit1@gmail.com> wrote:
>After my just submitted patch to include the aneg capability checking in
>genphy_c45_pma_read_abilities() function mv3310_get_features() isn't
>needed any longer and can be replaced with the generic one.
I'll still need it to handle the 2.5G/5G abilities that aren't
correctly reported on 3310. I'll be able to use the generic
function for the 2110 though, which is nice.
>But we can make this change afterwards, then you don't have to
>rework your series.
>
>Also I'm not sure whether there will be a 5.0-rc8 or whether beginning
>of next week we'll see 5.0. In the latter case we're a little bit in a
>hurry because the merge window will start very soon.
OK, I'll re-spin the series quickly with the small cleanup needed if
everything's OK to you regarding the rest of it.
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: Remove switchdev.h inclusion from team/bond/vlan
From: Andy Gospodarek @ 2019-02-22 20:47 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Jay Vosburgh, Veaceslav Falico, David S. Miller,
Jiri Pirko, Hangbin Liu, Richard Cochran, Davide Caratti,
Debabrata Banerjee, Sun Lianwen, open list
In-Reply-To: <20190222203134.19508-3-f.fainelli@gmail.com>
On Fri, Feb 22, 2019 at 12:31:34PM -0800, Florian Fainelli wrote:
> This is no longer necessary after eca59f691566 ("net: Remove support for bridge bypass ndos from stacked devices")
>
> Suggested-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andy Gospodarek <andy@greyhouse.net>
> ---
> drivers/net/bonding/bond_main.c | 1 -
> drivers/net/team/team.c | 1 -
> net/8021q/vlan_dev.c | 1 -
> 3 files changed, 3 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 485462d3087f..a044a8032a0f 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -77,7 +77,6 @@
> #include <net/pkt_sched.h>
> #include <linux/rculist.h>
> #include <net/flow_dissector.h>
> -#include <net/switchdev.h>
> #include <net/bonding.h>
> #include <net/bond_3ad.h>
> #include <net/bond_alb.h>
> diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
> index 958f1cf67282..3ff23a993668 100644
> --- a/drivers/net/team/team.c
> +++ b/drivers/net/team/team.c
> @@ -28,7 +28,6 @@
> #include <net/genetlink.h>
> #include <net/netlink.h>
> #include <net/sch_generic.h>
> -#include <net/switchdev.h>
> #include <generated/utsrelease.h>
> #include <linux/if_team.h>
>
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index b2d9c8f27cd7..15293c2a5dd8 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -31,7 +31,6 @@
> #include <linux/ethtool.h>
> #include <linux/phy.h>
> #include <net/arp.h>
> -#include <net/switchdev.h>
>
> #include "vlan.h"
> #include "vlanproc.h"
> --
> 2.17.1
>
^ permalink raw reply
* Re: pull-request: mac80211 2019-02-22
From: David Miller @ 2019-02-22 20:51 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190222131052.28249-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 22 Feb 2019 14:10:51 +0100
> So ... I thought there weren't going to be any more patches
> when I asked you to apply that mac80211 one, but now a few
> days later I still ended up with three that are current and
> possibly even stable material.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: pull-request: mac80211-next 2019-02-22
From: David Miller @ 2019-02-22 20:52 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190222132513.29834-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 22 Feb 2019 14:25:12 +0100
> Here's the promised update with the big multi-BSSID changes,
> which are related to HE (802.11ax) for which we also have some
> updates.
>
> Note that I took the liberty of including Herbert's rhashtable
> API removal, I merged net-next for that and verified that the
> API he removed is also not used in anything new, but if you
> apply/applied any patches after I pulled you should probably
> double check that again.
>
> Please pull and let me know if there's any problem.
Pulled, looks good on this end.
Will push back out after build testing.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v2 0/7] AF_PACKET transport_offset fix
From: David Miller @ 2019-02-22 20:55 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: maximmi, saeedm, willemb, jasowang, edumazet, netdev, eranbe,
tariqt
In-Reply-To: <CAF=yD-J4SLEYxvvjKkvofF+_YE0EDG_MmpQGQ9r6HT0RvFzdyQ@mail.gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Fri, 22 Feb 2019 09:20:01 -0500
> On Thu, Feb 21, 2019 at 7:40 AM Maxim Mikityanskiy <maximmi@mellanox.com> wrote:
>>
>> This patch series contains the implementation of the RFC that was posted
>> on this mailing list previously:
>> https://www.spinics.net/lists/netdev/msg541709.html
>>
>> It fixes having incorrect skb->transport_header values in cases when
>> dissect fails. Having correct values set by the kernel fixes mlx5
>> operation and allows to remove some unnecessary code flows in mlx5.
>>
>> v2 changes:
>>
>> - Rebase against the fresh net-next.
>> - Don't return bool from skb_probe_transport_header (and don't rename
>> the function).
>> - WARN_ON_ONCE and error path in case of GSO without the L4 header.
>>
>> Maxim Mikityanskiy (7):
>> net: Don't set transport offset to invalid value
>> net: Introduce parse_protocol header_ops callback
>> net/ethernet: Add parse_protocol header_ops support
>> net/packet: Ask driver for protocol if not provided by user
>> net/packet: Remove redundant skb->protocol set
>> net/mlx5e: Remove the wrong assumption about transport offset
>> net/mlx5e: Trust kernel regarding transport offset
>
> For the series: Acked-by: Willem de Bruijn <willemb@google.com>
Series applied, thanks.
^ 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