* r8169 driver causing screen flickering since commit a99790bf5c7f3d68d8b01e015d3212a98ee7bd57
From: Elias Rydberg @ 2019-02-15 10:44 UTC (permalink / raw)
To: netdev
Hi,
Since commit a99790bf5c7f3d68d8b01e015d3212a98ee7bd57, some systems have
experienced screen flickering, followed by a black screen, when using
WiFi (for example starting NetworkManager). So far this only seems to be
a problem with the following spec:
CPU: Intel i7-8550U
WiFi module: Intel AC-9260 1730Mbps
I contacted the author of the commit and got the following reply:
"From platforms I’ve seen, if ASPM on r8169 is disabled, the deepest
Package C-State on Intel CPU will limit to PC3.
If the ASPM on r8169 is enabled, it can reach to PC8 when the display is
on, and be able to reach PC10 when display is off.
So the issue seems to be a platform bug - deeper Package C state makes
your system unstable.
Please contact the system vendor, the deepest Package C state can be
reach should be set by BIOS."
Now, Kai-Heng suggest contacting the system vendor, but after consulting
my distributions forum, I got the suggestion of contacting this email
list in hope of implementing a patch disabling the ASPM in the r8169 in
systems with this spec. I apologize if this is a completely unreasonable
request; I'm not experienced with kernel developing.
Kind regards,
Elias Rydberg
Thread in my distributions forum, which includes more information:
https://bbs.archlinux.org/viewtopic.php?id=244115
<https://bbs.archlinux.org/viewtopic.php?id=244115>
The result of a kernel bisection I did:
|a99790bf5c7f3d68d8b01e015d3212a98ee7bd57 is the first bad commit commit
a99790bf5c7f3d68d8b01e015d3212a98ee7bd57 Author: Kai-Heng Feng
<kai.heng.feng@canonical.com <mailto:kai.heng.feng@canonical.com>> Date:
Thu Jun 21 16:30:39 2018 +0800 r8169: Reinstate ASPM Support On Intel
platforms (Skylake and newer), ASPM support in r8169 is the last missing
puzzle to let CPU's Package C-State reaches PC8. Without ASPM support,
the CPU cannot reach beyond PC3. PC8 can save additional ~3W in
comparison with PC3 on a Coffee Lake platform, Dell G3 3779. This is
based on the work from Chunhao Lin <hau@realtek.com
<mailto:hau@realtek.com>>. Signed-off-by: Kai-Heng Feng
<kai.heng.feng@canonical.com <mailto:kai.heng.feng@canonical.com>>
Signed-off-by: David S. Miller <davem@davemloft.net
<mailto:davem@davemloft.net>> :040000 040000
87d4515c14f8eb8cf99b6f47f97ca4db700931c1
e542595c74609136a7094777afb10b83012f6643 M drivers|
^ permalink raw reply
* Re: [PATCH net-next 02/12] net: sched: flower: refactor fl_change
From: Vlad Buslov @ 2019-02-15 10:38 UTC (permalink / raw)
To: Stefano Brivio
Cc: netdev@vger.kernel.org, jhs@mojatatu.com,
xiyou.wangcong@gmail.com, jiri@resnulli.us, davem@davemloft.net
In-Reply-To: <20190214213402.67919dea@redhat.com>
On Thu 14 Feb 2019 at 20:34, Stefano Brivio <sbrivio@redhat.com> wrote:
> On Thu, 14 Feb 2019 09:47:02 +0200
> Vlad Buslov <vladbu@mellanox.com> wrote:
>
>> As a preparation for using classifier spinlock instead of relying on
>> external rtnl lock, rearrange code in fl_change. The goal is to group the
>> code which changes classifier state in single block in order to allow
>> following commits in this set to protect it from parallel modification with
>> tp->lock. Data structures that require tp->lock protection are mask
>> hashtable and filters list, and classifier handle_idr.
>>
>> fl_hw_replace_filter() is a sleeping function and cannot be called while
>> holding a spinlock. In order to execute all sequence of changes to shared
>> classifier data structures atomically, call fl_hw_replace_filter() before
>> modifying them.
>>
>> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
>> Acked-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>> net/sched/cls_flower.c | 85 ++++++++++++++++++++++++++------------------------
>> 1 file changed, 44 insertions(+), 41 deletions(-)
>>
>> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
>> index 88d7af78ba7e..91596a6271f8 100644
>> --- a/net/sched/cls_flower.c
>> +++ b/net/sched/cls_flower.c
>> @@ -1354,90 +1354,93 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
>> if (err < 0)
>> goto errout;
>>
>> - if (!handle) {
>> - handle = 1;
>> - err = idr_alloc_u32(&head->handle_idr, fnew, &handle,
>> - INT_MAX, GFP_KERNEL);
>> - } else if (!fold) {
>> - /* user specifies a handle and it doesn't exist */
>> - err = idr_alloc_u32(&head->handle_idr, fnew, &handle,
>> - handle, GFP_KERNEL);
>> - }
>> - if (err)
>> - goto errout;
>> - fnew->handle = handle;
>> -
>>
>> [...]
>>
>> if (fold) {
>> + fnew->handle = handle;
>
> I'm probably missing something, but what if fold is passed and the
> handle isn't specified? That can still happen, right? In that case we
> wouldn't be allocating the handle.
Hi Stefano,
Thank you for reviewing my code.
Cls API lookups fold by handle, so this pointer can only be not NULL
when user specified a handle and filter with such handle exists on tp.
>
>> +
>> + err = rhashtable_insert_fast(&fnew->mask->ht, &fnew->ht_node,
>> + fnew->mask->filter_ht_params);
>> + if (err)
>> + goto errout_hw;
>> +
>> rhashtable_remove_fast(&fold->mask->ht,
>> &fold->ht_node,
>> fold->mask->filter_ht_params);
>> - if (!tc_skip_hw(fold->flags))
>> - fl_hw_destroy_filter(tp, fold, NULL);
>> - }
>> -
>> - *arg = fnew;
>> -
>> - if (fold) {
>> idr_replace(&head->handle_idr, fnew, fnew->handle);
>> list_replace_rcu(&fold->list, &fnew->list);
>> +
>> + if (!tc_skip_hw(fold->flags))
>> + fl_hw_destroy_filter(tp, fold, NULL);
>> tcf_unbind_filter(tp, &fold->res);
>> tcf_exts_get_net(&fold->exts);
>> tcf_queue_work(&fold->rwork, fl_destroy_filter_work);
>> } else {
>> + if (__fl_lookup(fnew->mask, &fnew->mkey)) {
>> + err = -EEXIST;
>> + goto errout_hw;
>> + }
>> +
>> + if (handle) {
>> + /* user specifies a handle and it doesn't exist */
>> + err = idr_alloc_u32(&head->handle_idr, fnew, &handle,
>> + handle, GFP_ATOMIC);
>> + } else {
>> + handle = 1;
>> + err = idr_alloc_u32(&head->handle_idr, fnew, &handle,
>> + INT_MAX, GFP_ATOMIC);
>> + }
>> + if (err)
>> + goto errout_hw;
>
> Just if you respin: a newline here would be nice to have.
Agree.
>
>> + fnew->handle = handle;
>> +
>> + err = rhashtable_insert_fast(&fnew->mask->ht, &fnew->ht_node,
>> + fnew->mask->filter_ht_params);
>> + if (err)
>> + goto errout_idr;
>> +
>> list_add_tail_rcu(&fnew->list, &fnew->mask->filters);
>> }
>>
>> + *arg = fnew;
>> +
>> kfree(tb);
>> kfree(mask);
>> return 0;
>>
>> -errout_mask_ht:
>> - rhashtable_remove_fast(&fnew->mask->ht, &fnew->ht_node,
>> - fnew->mask->filter_ht_params);
>> -
>> -errout_mask:
>> - fl_mask_put(head, fnew->mask, false);
>> -
>> errout_idr:
>> if (!fold)
>
> This check could go away, I guess (not a strong preference though).
Yes, it seems that after this change errout_idr lable is only accessed
from else branch of if(fold) conditional so the check is redundant.
>
>> idr_remove(&head->handle_idr, fnew->handle);
>> +errout_hw:
>> + if (!tc_skip_hw(fnew->flags))
>> + fl_hw_destroy_filter(tp, fnew, NULL);
>> +errout_mask:
>> + fl_mask_put(head, fnew->mask, false);
>> errout:
>> tcf_exts_destroy(&fnew->exts);
>> kfree(fnew);
^ permalink raw reply
* Re: [PATCH net-next] net: sched: sch_api: set an error msg when qdisc_alloc_handle() fails
From: Stefano Brivio @ 2019-02-15 10:30 UTC (permalink / raw)
To: Ivan Vecera; +Cc: netdev, Li Shuang
In-Reply-To: <20190215102325.30832-1-ivecera@redhat.com>
On Fri, 15 Feb 2019 11:23:25 +0100
Ivan Vecera <ivecera@redhat.com> wrote:
> This patch sets an error message in extack when the number of qdisc
> handles exceeds the maximum. Also the error-code ENOSPC is more
> appropriate than ENOMEM in this situation.
Reported-by: Li Shuang <shuali@redhat.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
--
Stefano
^ permalink raw reply
* Re: [PATCH net-next 2/3] ethtool: add compat for flash update
From: Jiri Pirko @ 2019-02-15 10:17 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, Jakub Kicinski, davem, oss-drivers, andrew
In-Reply-To: <20190215085315.GL25518@unicorn.suse.cz>
Fri, Feb 15, 2019 at 09:53:15AM CET, mkubecek@suse.cz wrote:
>On Thu, Feb 14, 2019 at 01:40:45PM -0800, Jakub Kicinski wrote:
>> If driver does not support ethtool flash update operation
>> call into devlink.
>>
>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> ---
>...
>> diff --git a/net/core/devlink.c b/net/core/devlink.c
>> index bd507e13bb7b..d169b5426d3d 100644
>> --- a/net/core/devlink.c
>> +++ b/net/core/devlink.c
>> @@ -6435,6 +6435,36 @@ void devlink_compat_running_version(struct net_device *dev,
>> mutex_unlock(&devlink_mutex);
>> }
>>
>> +int devlink_compat_flash_update(struct net_device *dev, const char *file_name)
>> +{
>> + struct devlink_port *devlink_port;
>> + struct devlink *devlink;
>> +
>> + 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);
>> +
>> + return -EOPNOTSUPP;
>> +}
>> +
>> static int __init devlink_module_init(void)
>> {
>> return genl_register_family(&devlink_nl_family);
>
>We already have similar lookup in devlink_compat_running_version() (the
>only difference seems to be that we keep holding devlink_mutex until the
>end there) and it's likely the net_device -> devlink lookup will be
>needed in more places in the future. How about having a helper for it?
>
>I also wonder how does the lookup scale. But I don't have clear idea
>how long the lists can become in real life and the ethtool operations
>are not really time critical.
Another thing is, that you don't really have to do the lookup. If you
have struct net_device *dev inside the driver, you can get the devlink
instance according to that. So it is just a matter of another ndo I
guess.
>
>Michal Kubecek
^ permalink raw reply
* Re: [PATCH net-next 3/3] nfp: devlink: allow flashing the device via devlink
From: Michal Kubecek @ 2019-02-15 10:26 UTC (permalink / raw)
To: netdev; +Cc: Jakub Kicinski, davem, jiri, oss-drivers, andrew
In-Reply-To: <20190214214046.19182-4-jakub.kicinski@netronome.com>
On Thu, Feb 14, 2019 at 01:40:46PM -0800, Jakub Kicinski wrote:
> Devlink now allows updating device flash. Implement this
> callback.
>
> Compared to ethtool update we no longer have to release
> the networking locks - devlink doesn't take them.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
...
> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> index cb9c512abc76..8f189149efc5 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> @@ -1237,11 +1237,8 @@ static int nfp_net_set_channels(struct net_device *netdev,
> static int
> nfp_net_flash_device(struct net_device *netdev, struct ethtool_flash *flash)
> {
> - const struct firmware *fw;
> struct nfp_app *app;
> - struct nfp_nsp *nsp;
> - struct device *dev;
> - int err;
> + int ret;
>
> if (flash->region != ETHTOOL_FLASH_ALL_REGIONS)
> return -EOPNOTSUPP;
> @@ -1250,39 +1247,13 @@ nfp_net_flash_device(struct net_device *netdev, struct ethtool_flash *flash)
> if (!app)
> return -EOPNOTSUPP;
>
> - dev = &app->pdev->dev;
> -
> - nsp = nfp_nsp_open(app->cpp);
> - if (IS_ERR(nsp)) {
> - err = PTR_ERR(nsp);
> - dev_err(dev, "Failed to access the NSP: %d\n", err);
> - return err;
> - }
> -
> - err = request_firmware_direct(&fw, flash->data, dev);
> - if (err)
> - goto exit_close_nsp;
> -
> - dev_info(dev, "Please be patient while writing flash image: %s\n",
> - flash->data);
> dev_hold(netdev);
> rtnl_unlock();
> -
> - err = nfp_nsp_write_flash(nsp, fw);
> - if (err < 0) {
> - dev_err(dev, "Flash write failed: %d\n", err);
> - goto exit_rtnl_lock;
> - }
> - dev_info(dev, "Finished writing flash image\n");
> -
> -exit_rtnl_lock:
> + ret = nfp_flash_update_common(app->pf, flash->data, NULL);
> rtnl_lock();
> dev_put(netdev);
> - release_firmware(fw);
>
> -exit_close_nsp:
> - nfp_nsp_close(nsp);
> - return err;
> + return ret;
> }
>
> static const struct ethtool_ops nfp_net_ethtool_ops = {
Out of curiosity: why don't you drop the ethtool_ops callback and let
the fallback introduced in patch 2/3 do the fallback? Is it to preserve
the check of flash->region or to avoid the lookup? My understanding of
the previous patch was that it would allow new drivers providing the
devlink callback to get rid of ethtool_ops one.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH net-next 3/3] nfp: devlink: allow flashing the device via devlink
From: Jiri Pirko @ 2019-02-15 10:15 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, oss-drivers, mkubecek, andrew
In-Reply-To: <20190214214046.19182-4-jakub.kicinski@netronome.com>
Thu, Feb 14, 2019 at 10:40:46PM CET, jakub.kicinski@netronome.com wrote:
>Devlink now allows updating device flash. Implement this
>callback.
>
>Compared to ethtool update we no longer have to release
>the networking locks - devlink doesn't take them.
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>---
> .../net/ethernet/netronome/nfp/nfp_devlink.c | 10 +++++
> drivers/net/ethernet/netronome/nfp/nfp_main.c | 41 +++++++++++++++++++
> drivers/net/ethernet/netronome/nfp/nfp_main.h | 2 +
> .../ethernet/netronome/nfp/nfp_net_ethtool.c | 35 ++--------------
> 4 files changed, 56 insertions(+), 32 deletions(-)
>
>diff --git a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
>index 080a301f379e..db2da99f6aa7 100644
>--- a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
>+++ b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
>@@ -330,6 +330,15 @@ nfp_devlink_info_get(struct devlink *devlink, struct devlink_info_req *req,
> return err;
> }
>
>+static int
>+nfp_devlink_flash_update(struct devlink *devlink, const char *path,
devlink code calles "path" a "file_name". It is good to be consistent in
this.
Other than this, the patch looks fine:
>+ const char *component, struct netlink_ext_ack *extack)
>+{
>+ if (component)
>+ return -EOPNOTSUPP;
>+ return nfp_flash_update_common(devlink_priv(devlink), path, extack);
>+}
>+
> const struct devlink_ops nfp_devlink_ops = {
> .port_split = nfp_devlink_port_split,
> .port_unsplit = nfp_devlink_port_unsplit,
>@@ -338,6 +347,7 @@ const struct devlink_ops nfp_devlink_ops = {
> .eswitch_mode_get = nfp_devlink_eswitch_mode_get,
> .eswitch_mode_set = nfp_devlink_eswitch_mode_set,
> .info_get = nfp_devlink_info_get,
>+ .flash_update = nfp_devlink_flash_update,
> };
>
> int nfp_devlink_port_register(struct nfp_app *app, struct nfp_port *port)
>diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c b/drivers/net/ethernet/netronome/nfp/nfp_main.c
>index 6c10e8d119e4..f4c8776e42b6 100644
>--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
>+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
>@@ -300,6 +300,47 @@ static int nfp_pcie_sriov_configure(struct pci_dev *pdev, int num_vfs)
> return nfp_pcie_sriov_enable(pdev, num_vfs);
> }
>
>+int nfp_flash_update_common(struct nfp_pf *pf, const char *path,
>+ struct netlink_ext_ack *extack)
>+{
>+ struct device *dev = &pf->pdev->dev;
>+ const struct firmware *fw;
>+ struct nfp_nsp *nsp;
>+ int err;
>+
>+ nsp = nfp_nsp_open(pf->cpp);
>+ if (IS_ERR(nsp)) {
>+ err = PTR_ERR(nsp);
>+ if (extack)
>+ NL_SET_ERR_MSG_MOD(extack, "can't access NSP");
>+ else
>+ dev_err(dev, "Failed to access the NSP: %d\n", err);
>+ return err;
>+ }
>+
>+ err = request_firmware_direct(&fw, path, dev);
>+ if (err) {
>+ NL_SET_ERR_MSG_MOD(extack,
>+ "unable to read flash file from disk");
>+ goto exit_close_nsp;
>+ }
>+
>+ dev_info(dev, "Please be patient while writing flash image: %s\n",
>+ path);
>+
>+ err = nfp_nsp_write_flash(nsp, fw);
>+ if (err < 0)
>+ goto exit_release_fw;
>+ dev_info(dev, "Finished writing flash image\n");
>+ err = 0;
>+
>+exit_release_fw:
>+ release_firmware(fw);
>+exit_close_nsp:
>+ nfp_nsp_close(nsp);
>+ return err;
>+}
>+
> static const struct firmware *
> nfp_net_fw_request(struct pci_dev *pdev, struct nfp_pf *pf, const char *name)
> {
>diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.h b/drivers/net/ethernet/netronome/nfp/nfp_main.h
>index a3613a2e0aa5..b7211f200d22 100644
>--- a/drivers/net/ethernet/netronome/nfp/nfp_main.h
>+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.h
>@@ -164,6 +164,8 @@ nfp_pf_map_rtsym(struct nfp_pf *pf, const char *name, const char *sym_fmt,
> unsigned int min_size, struct nfp_cpp_area **area);
> int nfp_mbox_cmd(struct nfp_pf *pf, u32 cmd, void *in_data, u64 in_length,
> void *out_data, u64 out_length);
>+int nfp_flash_update_common(struct nfp_pf *pf, const char *path,
>+ struct netlink_ext_ack *extack);
>
> enum nfp_dump_diag {
> NFP_DUMP_NSP_DIAG = 0,
>diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
>index cb9c512abc76..8f189149efc5 100644
>--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
>+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
>@@ -1237,11 +1237,8 @@ static int nfp_net_set_channels(struct net_device *netdev,
> static int
> nfp_net_flash_device(struct net_device *netdev, struct ethtool_flash *flash)
> {
>- const struct firmware *fw;
> struct nfp_app *app;
>- struct nfp_nsp *nsp;
>- struct device *dev;
>- int err;
>+ int ret;
>
> if (flash->region != ETHTOOL_FLASH_ALL_REGIONS)
> return -EOPNOTSUPP;
>@@ -1250,39 +1247,13 @@ nfp_net_flash_device(struct net_device *netdev, struct ethtool_flash *flash)
> if (!app)
> return -EOPNOTSUPP;
>
>- dev = &app->pdev->dev;
>-
>- nsp = nfp_nsp_open(app->cpp);
>- if (IS_ERR(nsp)) {
>- err = PTR_ERR(nsp);
>- dev_err(dev, "Failed to access the NSP: %d\n", err);
>- return err;
>- }
>-
>- err = request_firmware_direct(&fw, flash->data, dev);
>- if (err)
>- goto exit_close_nsp;
>-
>- dev_info(dev, "Please be patient while writing flash image: %s\n",
>- flash->data);
> dev_hold(netdev);
> rtnl_unlock();
>-
>- err = nfp_nsp_write_flash(nsp, fw);
>- if (err < 0) {
>- dev_err(dev, "Flash write failed: %d\n", err);
>- goto exit_rtnl_lock;
>- }
>- dev_info(dev, "Finished writing flash image\n");
>-
>-exit_rtnl_lock:
>+ ret = nfp_flash_update_common(app->pf, flash->data, NULL);
> rtnl_lock();
> dev_put(netdev);
>- release_firmware(fw);
>
>-exit_close_nsp:
>- nfp_nsp_close(nsp);
>- return err;
>+ return ret;
> }
>
> static const struct ethtool_ops nfp_net_ethtool_ops = {
Why don't you use the compat fallback? I think you should.
>--
>2.19.2
>
^ permalink raw reply
* [PATCH net-next] net: sched: sch_api: set an error msg when qdisc_alloc_handle() fails
From: Ivan Vecera @ 2019-02-15 10:23 UTC (permalink / raw)
To: netdev
This patch sets an error message in extack when the number of qdisc
handles exceeds the maximum. Also the error-code ENOSPC is more
appropriate than ENOMEM in this situation.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
net/sched/sch_api.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 2283924fb56d..b8a388e4bcc4 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1201,9 +1201,11 @@ static struct Qdisc *qdisc_create(struct net_device *dev,
} else {
if (handle == 0) {
handle = qdisc_alloc_handle(dev);
- err = -ENOMEM;
- if (handle == 0)
+ if (handle == 0) {
+ NL_SET_ERR_MSG(extack, "Maximum number of qdisc handles was exceeded");
+ err = -ENOSPC;
goto err_out3;
+ }
}
if (!netif_is_multiqueue(dev))
sch->flags |= TCQ_F_ONETXQUEUE;
--
2.19.2
^ permalink raw reply related
* Re: [PATCH net-next 2/3] ethtool: add compat for flash update
From: Jiri Pirko @ 2019-02-15 10:12 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, oss-drivers, mkubecek, andrew
In-Reply-To: <20190214214046.19182-3-jakub.kicinski@netronome.com>
Thu, Feb 14, 2019 at 10:40:45PM CET, jakub.kicinski@netronome.com wrote:
>If driver does not support ethtool flash update operation
>call into devlink.
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/3] devlink: add flash update command
From: Jiri Pirko @ 2019-02-15 10:10 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, oss-drivers, mkubecek, andrew
In-Reply-To: <20190214214046.19182-2-jakub.kicinski@netronome.com>
Thu, Feb 14, 2019 at 10:40:44PM CET, jakub.kicinski@netronome.com wrote:
>Add devlink flash update command. Advanced NICs have firmware
>stored in flash and often cryptographically secured. Updating
>that flash is handled by management firmware. Ethtool has a
>flash update command which served us well, however, it has two
>shortcomings:
> - it takes rtnl_lock unnecessarily - really flash update has
> nothing to do with networking, so using a networking device
> as a handle is suboptimal, which leads us to the second one:
> - it requires a functioning netdev - in case device enters an
> error state and can't spawn a netdev (e.g. communication
> with the device fails) there is no netdev to use as a handle
> for flashing.
>
>Devlink already has the ability to report the firmware versions,
>now with the ability to update the firmware/flash we will be
>able to recover devices in bad state.
>
>To enable updates of sub-components of the FW allow passing
>component name. This name should correspond to one of the
>versions reported in devlink info.
>
>v1: - replace target id with component name (Jiri).
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* ip xfrm policy, dir out vs dir fwd
From: Oleg @ 2019-02-15 10:11 UTC (permalink / raw)
To: netdev
Hi, all.
I don't understand why i need to create dir out policy for transit
ipsec traffic?
For example(conf from 192.168.77.1; it acts as a gateway between world and
private network behind 192.168.77.35):
ip xfrm policy add src 192.168.77.35 dst 0.0.0.0/0 dir fwd tmpl src 192.168.77.35 dst 192.168.77.1 proto esp reqid 1 mode tunnel
ip xfrm policy add src 0.0.0.0/0 dst 192.168.77.35 dir fwd tmpl src 192.168.77.1 dst 192.168.77.35 proto esp reqid 2 mode tunnel
doesn't work. But:
ip xfrm policy add src 192.168.77.35 dst 0.0.0.0/0 dir fwd tmpl src 192.168.77.35 dst 192.168.77.1 proto esp reqid 1 mode tunnel
ip xfrm policy add src 0.0.0.0/0 dst 192.168.77.35 dir out tmpl src 192.168.77.1 dst 192.168.77.35 proto esp reqid 2 mode tunnel
works well.
May be anybody can help me with this?
Thanks!
--
Олег Неманов (Oleg Nemanov)
^ permalink raw reply
* Re: [PATCH] net: phy: at803x: disable delay only for RGMII mode
From: Vinod Koul @ 2019-02-15 10:16 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: David S Miller, linux-arm-msm, Bjorn Andersson, netdev,
Niklas Cassel, Andrew Lunn, Florian Fainelli, Nori, Sekhar,
Marc Gonzalez
In-Reply-To: <89c39811-b100-564a-da40-abf46e450c95@ti.com>
On 13-02-19, 09:02, Peter Ujfalusi wrote:
> Hi Vinod,
>
> On 12/02/2019 16.19, Vinod Koul wrote:
> > Per "Documentation/devicetree/bindings/net/ethernet.txt" RGMII mode
> > should not have delay in PHY whereas RGMII_ID and RGMII_RXID/RGMII_TXID
> > can have delay in phy.
> >
> > So disable the delay only for RGMII mode and disable for other modes
> s/disable for other modes/enable for other modes
oops
>
> Works fine on am335x-evmsk:
> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Thanks for quick testing..
>
> and few comment
>
> > Fixes: cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode")
> > Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> > Signed-off-by: Vinod Koul <vkoul@kernel.org>
> > ---
> > drivers/net/phy/at803x.c | 33 ++++++++++++++++++++++++++-------
> > 1 file changed, 26 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> > index 8ff12938ab47..7b54b54e3316 100644
> > --- a/drivers/net/phy/at803x.c
> > +++ b/drivers/net/phy/at803x.c
> > @@ -110,6 +110,18 @@ static int at803x_debug_reg_mask(struct phy_device *phydev, u16 reg,
> > return phy_write(phydev, AT803X_DEBUG_DATA, val);
> > }
> >
> > +static inline int at803x_enable_rx_delay(struct phy_device *phydev)
> > +{
> > + return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0, 0,
> > + AT803X_DEBUG_RX_CLK_DLY_EN);
> > +}
>
> static inline int at803x_select_rx_delay(struct phy_device *phydev,
> bool enable)
> {
> }
>
> > +
> > +static inline int at803x_enable_tx_delay(struct phy_device *phydev)
> > +{
> > + return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_5, 0,
> > + AT803X_DEBUG_TX_CLK_DLY_EN);
> > +}
>
> static inline int at803x_select_tx_delay(struct phy_device *phydev,
> bool enable)
> {
> }
>
> perhaps?
Given that we would again branch off on enable, I see this as no better
case so I will keep existing
>
> > +
> > static inline int at803x_disable_rx_delay(struct phy_device *phydev)
> > {
> > return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0,
> > @@ -255,18 +267,25 @@ static int at803x_config_init(struct phy_device *phydev)
> > if (ret < 0)
> > return ret;
> >
> > - if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
> > - phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> > - phydev->interface == PHY_INTERFACE_MODE_RGMII) {
> > + if (phydev->interface == PHY_INTERFACE_MODE_RGMII) {
> > ret = at803x_disable_rx_delay(phydev);
> > if (ret < 0)
> > return ret;
> > + ret = at803x_disable_tx_delay(phydev);
> > + if (ret < 0)
> > + return ret;
>
> is it a possibility to have PHY_INTERFACE_MODE_RGMII and other RGMII_ID
> || RGMII_TXID || RGMII_RXID set at the same time?
Nope that would not make sense
> if not you can just return from here, no need to check for other RGMII
> modes?
for RGMII yes indeed..
--
~Vinod
^ permalink raw reply
* [PATCH net-next v2 0/3] enetc: Add mdio support and device tree nodes
From: Claudiu Manoil @ 2019-02-15 10:10 UTC (permalink / raw)
To: Shawn Guo, Li Yang, David S . Miller
Cc: alexandru.marginean, linux-arm-kernel, devicetree, netdev,
linux-kernel
This is the missing part to enable PCI probing of the ENETC ethernet
ports on the LS1028A SoC and external traffic on the LS1028A RDB board.
It's one of the first items on the TODO list for the recently merged
ENETC ethernet driver.
Claudiu Manoil (3):
arm64: dts: fsl: ls1028a: Add PCI IERC node and ENETC endpoints
arm64: dts: fsl: ls1028a-rdb: Add ENETC external eth ports for the
LS1028A RDB board
enetc: Add ENETC PF level external MDIO support
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 17 ++
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 33 ++++
drivers/net/ethernet/freescale/enetc/Makefile | 3 +-
drivers/net/ethernet/freescale/enetc/enetc_mdio.c | 199 ++++++++++++++++++++++
drivers/net/ethernet/freescale/enetc/enetc_pf.c | 12 ++
drivers/net/ethernet/freescale/enetc/enetc_pf.h | 6 +
6 files changed, 269 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_mdio.c
--
2.7.4
^ permalink raw reply
* [PATCH net-next v2 3/3] enetc: Add ENETC PF level external MDIO support
From: Claudiu Manoil @ 2019-02-15 10:10 UTC (permalink / raw)
To: Shawn Guo, Li Yang, David S . Miller
Cc: alexandru.marginean, linux-arm-kernel, devicetree, netdev,
linux-kernel
In-Reply-To: <1550225414-12125-1-git-send-email-claudiu.manoil@nxp.com>
Each ENETC PF has its own MDIO interface, the corresponding
MDIO registers are mapped in the ENETC's Port register block.
The current patch adds a driver for these PF level MDIO buses,
so that each PF can manage directly its own external link.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - used readx_poll_timeout()
- added mdio node child to the port node
- added code comments, removed redundant err messages,
minor code cleanup
drivers/net/ethernet/freescale/enetc/Makefile | 3 +-
drivers/net/ethernet/freescale/enetc/enetc_mdio.c | 199 ++++++++++++++++++++++
drivers/net/ethernet/freescale/enetc/enetc_pf.c | 12 ++
drivers/net/ethernet/freescale/enetc/enetc_pf.h | 6 +
4 files changed, 219 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_mdio.c
diff --git a/drivers/net/ethernet/freescale/enetc/Makefile b/drivers/net/ethernet/freescale/enetc/Makefile
index 6976602..7139e41 100644
--- a/drivers/net/ethernet/freescale/enetc/Makefile
+++ b/drivers/net/ethernet/freescale/enetc/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_FSL_ENETC) += fsl-enetc.o
-fsl-enetc-$(CONFIG_FSL_ENETC) += enetc.o enetc_cbdr.o enetc_ethtool.o
+fsl-enetc-$(CONFIG_FSL_ENETC) += enetc.o enetc_cbdr.o enetc_ethtool.o \
+ enetc_mdio.o
fsl-enetc-$(CONFIG_PCI_IOV) += enetc_msg.o
fsl-enetc-objs := enetc_pf.o $(fsl-enetc-y)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
new file mode 100644
index 0000000..f715487
--- /dev/null
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/* Copyright 2019 NXP */
+
+#include <linux/mdio.h>
+#include <linux/of_mdio.h>
+#include <linux/iopoll.h>
+#include <linux/of.h>
+
+#include "enetc_pf.h"
+
+struct enetc_mdio_regs {
+ u32 mdio_cfg; /* MDIO configuration and status */
+ u32 mdio_ctl; /* MDIO control */
+ u32 mdio_data; /* MDIO data */
+ u32 mdio_addr; /* MDIO address */
+};
+
+#define bus_to_enetc_regs(bus) (struct enetc_mdio_regs __iomem *)((bus)->priv)
+
+#define ENETC_MDIO_REG_OFFSET 0x1c00
+#define ENETC_MDC_DIV 258
+
+#define MDIO_CFG_CLKDIV(x) ((((x) >> 1) & 0xff) << 8)
+#define MDIO_CFG_BSY BIT(0)
+#define MDIO_CFG_RD_ER BIT(1)
+#define MDIO_CFG_ENC45 BIT(6)
+ /* external MDIO only - driven on neg MDC edge */
+#define MDIO_CFG_NEG BIT(23)
+
+#define MDIO_CTL_DEV_ADDR(x) ((x) & 0x1f)
+#define MDIO_CTL_PORT_ADDR(x) (((x) & 0x1f) << 5)
+#define MDIO_CTL_READ BIT(15)
+#define MDIO_DATA(x) ((x) & 0xffff)
+
+#define TIMEOUT 1000
+static int enetc_mdio_wait_complete(struct enetc_mdio_regs __iomem *regs)
+{
+ u32 val;
+
+ return readx_poll_timeout(enetc_rd_reg, ®s->mdio_cfg, val,
+ !(val & MDIO_CFG_BSY), 10, 10 * TIMEOUT);
+}
+
+static int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
+ u16 value)
+{
+ struct enetc_mdio_regs __iomem *regs = bus_to_enetc_regs(bus);
+ u32 mdio_ctl, mdio_cfg;
+ u16 dev_addr;
+ int ret;
+
+ mdio_cfg = MDIO_CFG_CLKDIV(ENETC_MDC_DIV) | MDIO_CFG_NEG;
+ if (regnum & MII_ADDR_C45) {
+ dev_addr = (regnum >> 16) & 0x1f;
+ mdio_cfg |= MDIO_CFG_ENC45;
+ } else {
+ /* clause 22 (ie 1G) */
+ dev_addr = regnum & 0x1f;
+ mdio_cfg &= ~MDIO_CFG_ENC45;
+ }
+
+ enetc_wr_reg(®s->mdio_cfg, mdio_cfg);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+
+ /* set port and dev addr */
+ mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
+ enetc_wr_reg(®s->mdio_ctl, mdio_ctl);
+
+ /* set the register address */
+ if (regnum & MII_ADDR_C45) {
+ enetc_wr_reg(®s->mdio_addr, regnum & 0xffff);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+ }
+
+ /* write the value */
+ enetc_wr_reg(®s->mdio_data, MDIO_DATA(value));
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int enetc_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
+{
+ struct enetc_mdio_regs __iomem *regs = bus_to_enetc_regs(bus);
+ u32 mdio_ctl, mdio_cfg;
+ u16 dev_addr, value;
+ int ret;
+
+ mdio_cfg = MDIO_CFG_CLKDIV(ENETC_MDC_DIV) | MDIO_CFG_NEG;
+ if (regnum & MII_ADDR_C45) {
+ dev_addr = (regnum >> 16) & 0x1f;
+ mdio_cfg |= MDIO_CFG_ENC45;
+ } else {
+ dev_addr = regnum & 0x1f;
+ mdio_cfg &= ~MDIO_CFG_ENC45;
+ }
+
+ enetc_wr_reg(®s->mdio_cfg, mdio_cfg);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+
+ /* set port and device addr */
+ mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
+ enetc_wr_reg(®s->mdio_ctl, mdio_ctl);
+
+ /* set the register address */
+ if (regnum & MII_ADDR_C45) {
+ enetc_wr_reg(®s->mdio_addr, regnum & 0xffff);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+ }
+
+ /* initiate the read */
+ enetc_wr_reg(®s->mdio_ctl, mdio_ctl | MDIO_CTL_READ);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+
+ /* return all Fs if nothing was there */
+ if (enetc_rd_reg(®s->mdio_cfg) & MDIO_CFG_RD_ER) {
+ dev_err(&bus->dev,
+ "Error while reading PHY%d reg at %d.%hhu\n",
+ phy_id, dev_addr, regnum);
+ return 0xffff;
+ }
+
+ value = enetc_rd_reg(®s->mdio_data) & 0xffff;
+
+ return value;
+}
+
+int enetc_mdio_probe(struct enetc_pf *pf)
+{
+ struct device *dev = &pf->si->pdev->dev;
+ struct enetc_mdio_regs __iomem *regs;
+ struct device_node *np;
+ struct mii_bus *bus;
+ int ret;
+
+ bus = mdiobus_alloc_size(sizeof(regs));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = "Freescale ENETC MDIO Bus";
+ bus->read = enetc_mdio_read;
+ bus->write = enetc_mdio_write;
+ bus->parent = dev;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
+
+ /* store the enetc mdio base address for this bus */
+ regs = pf->si->hw.port + ENETC_MDIO_REG_OFFSET;
+ bus->priv = regs;
+
+ np = of_get_child_by_name(dev->of_node, "mdio");
+ if (!np) {
+ dev_err(dev, "MDIO node missing\n");
+ ret = -EINVAL;
+ goto err_registration;
+ }
+
+ ret = of_mdiobus_register(bus, np);
+ if (ret) {
+ of_node_put(np);
+ dev_err(dev, "cannot register MDIO bus\n");
+ goto err_registration;
+ }
+
+ of_node_put(np);
+ pf->mdio = bus;
+
+ return 0;
+
+err_registration:
+ mdiobus_free(bus);
+
+ return ret;
+}
+
+void enetc_mdio_remove(struct enetc_pf *pf)
+{
+ if (pf->mdio) {
+ mdiobus_unregister(pf->mdio);
+ mdiobus_free(pf->mdio);
+ }
+}
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 7d28f5e..15876a6 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -746,6 +746,7 @@ static void enetc_pf_netdev_setup(struct enetc_si *si, struct net_device *ndev,
static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
{
+ struct enetc_pf *pf = enetc_si_priv(priv->si);
struct device_node *np = priv->dev->of_node;
int err;
@@ -770,12 +771,22 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
priv->phy_node = of_node_get(np);
}
+ if (!of_phy_is_fixed_link(np)) {
+ err = enetc_mdio_probe(pf);
+ if (err) {
+ of_node_put(priv->phy_node);
+ return err;
+ }
+ }
+
priv->if_mode = of_get_phy_mode(np);
if (priv->if_mode < 0) {
dev_err(priv->dev, "missing phy type\n");
of_node_put(priv->phy_node);
if (of_phy_is_fixed_link(np))
of_phy_deregister_fixed_link(np);
+ else
+ enetc_mdio_remove(pf);
return -EINVAL;
}
@@ -898,6 +909,7 @@ static void enetc_pf_remove(struct pci_dev *pdev)
unregister_netdev(si->ndev);
+ enetc_mdio_remove(pf);
enetc_of_put_phy(priv);
enetc_free_msix(priv);
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.h b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
index 2061ae5..10dd1b5 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
@@ -42,8 +42,14 @@ struct enetc_pf {
char vlan_promisc_simap; /* bitmap of SIs in VLAN promisc mode */
DECLARE_BITMAP(vlan_ht_filter, ENETC_VLAN_HT_SIZE);
DECLARE_BITMAP(active_vlans, VLAN_N_VID);
+
+ struct mii_bus *mdio; /* saved for cleanup */
};
int enetc_msg_psi_init(struct enetc_pf *pf);
void enetc_msg_psi_free(struct enetc_pf *pf);
void enetc_msg_handle_rxmsg(struct enetc_pf *pf, int mbox_id, u16 *status);
+
+/* MDIO */
+int enetc_mdio_probe(struct enetc_pf *pf);
+void enetc_mdio_remove(struct enetc_pf *pf);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 2/3] arm64: dts: fsl: ls1028a-rdb: Add ENETC external eth ports for the LS1028A RDB board
From: Claudiu Manoil @ 2019-02-15 10:10 UTC (permalink / raw)
To: Shawn Guo, Li Yang, David S . Miller
Cc: alexandru.marginean, linux-arm-kernel, devicetree, netdev,
linux-kernel
In-Reply-To: <1550225414-12125-1-git-send-email-claudiu.manoil@nxp.com>
The LS1028A RDB board features an Atheros PHY connected over
SGMII to the ENETC PF0 (or Port0). ENETC Port1 (PF1) has no
external connection on this board, so it can be disabled for now.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - added a mdio node as parent for the phy node
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index fdeb417..f86b054 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -71,3 +71,20 @@
&duart1 {
status = "okay";
};
+
+&enetc_port0 {
+ phy-handle = <&sgmii_phy0>;
+ phy-connection-type = "sgmii";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sgmii_phy0: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+ };
+};
+
+&enetc_port1 {
+ status = "disabled";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 1/3] arm64: dts: fsl: ls1028a: Add PCI IERC node and ENETC endpoints
From: Claudiu Manoil @ 2019-02-15 10:10 UTC (permalink / raw)
To: Shawn Guo, Li Yang, David S . Miller
Cc: alexandru.marginean, linux-arm-kernel, devicetree, netdev,
linux-kernel
In-Reply-To: <1550225414-12125-1-git-send-email-claudiu.manoil@nxp.com>
The LS1028A SoC features a PCI Integrated Endpoint Root Complex
(IERC) defining several integrated PCI devices, including the ENETC
ethernet controller integrated endpoints (IEPs). The IERC implements
ECAM (Enhanced Configuration Access Mechanism) to provide access
to the PCIe config space of the IEPs. This means the the IEPs
(including ENETC) do not support the standard PCIe BARs, instead
the Enhanced Allocation (EA) capability structures in the ECAM space
are used to fix the base addresses in the system, and the PCI
subsystem uses these structures for device enumeration and discovery.
The "ranges" entries contain basic information from these EA capabily
structures required by the kernel for device enumeration.
The current patch also enables the first 2 ENETC PFs (Physiscal
Functions) and the associated VFs (Virtual Functions), 2 VFs for
each PF. Each of these ENETC PFs has an external ethernet port
on the LS1028A SoC.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - none
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 33 ++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index a8cf92a..7f5a8e6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -335,5 +335,38 @@
<GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ pcie@1f0000000 { /* Integrated Endpoint Root Complex */
+ compatible = "pci-host-ecam-generic";
+ reg = <0x01 0xf0000000 0x0 0x100000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ msi-parent = <&its>;
+ device_type = "pci";
+ bus-range = <0x0 0x0>;
+ dma-coherent;
+ msi-map = <0 &its 0x17 0xe>;
+ iommu-map = <0 &smmu 0x17 0xe>;
+ /* PF0-6 BAR0 - non-prefetchable memory */
+ ranges = <0x82000000 0x0 0x00000000 0x1 0xf8000000 0x0 0x160000
+ /* PF0-6 BAR2 - prefetchable memory */
+ 0xc2000000 0x0 0x00000000 0x1 0xf8160000 0x0 0x070000
+ /* PF0: VF0-1 BAR0 - non-prefetchable memory */
+ 0x82000000 0x0 0x00000000 0x1 0xf81d0000 0x0 0x020000
+ /* PF0: VF0-1 BAR2 - prefetchable memory */
+ 0xc2000000 0x0 0x00000000 0x1 0xf81f0000 0x0 0x020000
+ /* PF1: VF0-1 BAR0 - non-prefetchable memory */
+ 0x82000000 0x0 0x00000000 0x1 0xf8210000 0x0 0x020000
+ /* PF1: VF0-1 BAR2 - prefetchable memory */
+ 0xc2000000 0x0 0x00000000 0x1 0xf8230000 0x0 0x020000>;
+
+ enetc_port0: pci@0,0 {
+ reg = <0x000000 0 0 0 0>;
+ };
+ enetc_port1: pci@0,1 {
+ reg = <0x000100 0 0 0 0>;
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v4 07/17] net: sched: protect filter_chain list with filter_chain_lock mutex
From: Vlad Buslov @ 2019-02-15 10:02 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev@vger.kernel.org, jhs@mojatatu.com,
xiyou.wangcong@gmail.com, jiri@resnulli.us, davem@davemloft.net,
ast@kernel.org, daniel@iogearbox.net
In-Reply-To: <20190214182442.GA19269@splinter>
On Thu 14 Feb 2019 at 18:24, Ido Schimmel <idosch@idosch.org> wrote:
> On Mon, Feb 11, 2019 at 10:55:38AM +0200, Vlad Buslov wrote:
>> Extend tcf_chain with new filter_chain_lock mutex. Always lock the chain
>> when accessing filter_chain list, instead of relying on rtnl lock.
>> Dereference filter_chain with tcf_chain_dereference() lockdep macro to
>> verify that all users of chain_list have the lock taken.
>>
>> Rearrange tp insert/remove code in tc_new_tfilter/tc_del_tfilter to execute
>> all necessary code while holding chain lock in order to prevent
>> invalidation of chain_info structure by potential concurrent change. This
>> also serializes calls to tcf_chain0_head_change(), which allows head change
>> callbacks to rely on filter_chain_lock for synchronization instead of rtnl
>> mutex.
>>
>> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
>> Acked-by: Jiri Pirko <jiri@mellanox.com>
>
> With this sequence [1] I get the following trace [2]. Bisected it to
> this patch. Note that second filter is rejected by the device driver
> (that's the intention). I guess it is not properly removed from the
> filter chain in the error path?
>
> Thanks
>
> [1]
> # tc qdisc add dev swp3 clsact
> # tc filter add dev swp3 ingress pref 1 matchall skip_sw \
> action mirred egress mirror dev swp7
> # tc filter add dev swp3 ingress pref 2 matchall skip_sw \
> action mirred egress mirror dev swp7
> RTNETLINK answers: File exists
> We have an error talking to the kernel, -1
> # tc qdisc del dev swp3 clsact
>
> [2]
> [ 70.545131] kasan: GPF could be caused by NULL-ptr deref or user memory access
> [ 70.553394] general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
> [ 70.560618] CPU: 2 PID: 2268 Comm: tc Not tainted 5.0.0-rc5-custom-02103-g415d39427317 #1304
> [ 70.570065] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
> [ 70.580204] RIP: 0010:mall_reoffload+0x14a/0x760
> [ 70.585382] Code: c1 0f 85 ba 05 00 00 31 c0 4d 8d 6c 24 34 b9 06 00 00 00 4c 89 ff f3 48 ab 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 14 02 4c 89 e8 83
> e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 bd
> [ 70.606382] RSP: 0018:ffff888231faefc0 EFLAGS: 00010207
> [ 70.612235] RAX: dffffc0000000000 RBX: 1ffff110463f5dfe RCX: 0000000000000000
> [ 70.620220] RDX: 0000000000000006 RSI: 1ffff110463f5e01 RDI: ffff888231faf040
> [ 70.628206] RBP: ffff8881ef151a00 R08: 0000000000000000 R09: ffffed10463f5dfa
> [ 70.636192] R10: ffffed10463f5dfa R11: 0000000000000003 R12: 0000000000000000
> [ 70.644177] R13: 0000000000000034 R14: 0000000000000000 R15: ffff888231faf010
> [ 70.652163] FS: 00007f46b5bf0800(0000) GS:ffff888236c00000(0000) knlGS:0000000000000000
> [ 70.661218] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 70.667649] CR2: 0000000001d590a8 CR3: 0000000231c3c000 CR4: 00000000001006e0
> [ 70.675633] Call Trace:
> [ 70.693046] tcf_block_playback_offloads+0x94/0x230
> [ 70.710617] __tcf_block_cb_unregister+0xf7/0x2d0
> [ 70.734143] mlxsw_sp_setup_tc+0x20f/0x660
> [ 70.738739] tcf_block_offload_unbind+0x22b/0x350
> [ 70.748898] __tcf_block_put+0x203/0x630
> [ 70.769700] tcf_block_put_ext+0x2f/0x40
> [ 70.774098] clsact_destroy+0x7a/0xb0
> [ 70.782604] qdisc_destroy+0x11a/0x5c0
> [ 70.786810] qdisc_put+0x5a/0x70
> [ 70.790435] notify_and_destroy+0x8e/0xa0
> [ 70.794933] qdisc_graft+0xbb7/0xef0
> [ 70.809009] tc_get_qdisc+0x518/0xa30
> [ 70.821530] rtnetlink_rcv_msg+0x397/0xa20
> [ 70.835510] netlink_rcv_skb+0x132/0x380
> [ 70.848419] netlink_unicast+0x4c0/0x690
> [ 70.866019] netlink_sendmsg+0x929/0xe10
> [ 70.882134] sock_sendmsg+0xc8/0x110
> [ 70.886144] ___sys_sendmsg+0x77a/0x8f0
> [ 70.924064] __sys_sendmsg+0xf7/0x250
> [ 70.955727] do_syscall_64+0x14d/0x610
Hi Ido,
Thanks for reporting this.
I looked at the code and problem seems to be matchall classifier
specific. My implementation of unlocked cls API assumes that concurrent
insertions are possible and checks for it when deleting "empty" tp.
Since classifiers don't expose number of elements, the only way to test
this is to do tp->walk() on them and assume that walk callback is called
once per filter on every classifier. In your example new tp is created
for second filter, filter insertion fails, number of elements on newly
created tp is checked with tp->walk() before deleting it. However,
matchall classifier always calls the tp->walk() callback once, even when
it doesn't have a valid filter (in this case with NULL filter pointer).
Possible ways to fix this:
1) Check for NULL filter pointer in tp->walk() callback and ignore it
when counting filters on tp - will work but I don't like it because I
don't think it is ever correct to call tp->walk() callback with NULL
filter pointer.
2) Fix matchall to not call tp->walk() callback with NULL filter
pointers - my preferred simple solution.
3) Extend tp API to have direct way to count filters by implementing
tp->count - requires change to every classifier. Or maybe add it as
optional API that only unlocked classifiers are required to implement
and just delete rtnl lock dependent tp's without checking for concurrent
insertions.
What do you think?
Regards,
Vlad
^ permalink raw reply
* Re: [PATCH] net: phy: at803x: disable delay only for RGMII mode
From: Vinod Koul @ 2019-02-15 9:58 UTC (permalink / raw)
To: David Miller
Cc: linux-arm-msm, bjorn.andersson, netdev, niklas.cassel, andrew,
f.fainelli, nsekhar, peter.ujfalusi, marc.w.gonzalez
In-Reply-To: <20190214.083828.206479765039661735.davem@davemloft.net>
On 14-02-19, 08:38, David Miller wrote:
> From: Vinod Koul <vkoul@kernel.org>
> Date: Tue, 12 Feb 2019 19:49:22 +0530
>
> > diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> > index 8ff12938ab47..7b54b54e3316 100644
> > --- a/drivers/net/phy/at803x.c
> > +++ b/drivers/net/phy/at803x.c
> > @@ -110,6 +110,18 @@ static int at803x_debug_reg_mask(struct phy_device *phydev, u16 reg,
> > return phy_write(phydev, AT803X_DEBUG_DATA, val);
> > }
> >
> > +static inline int at803x_enable_rx_delay(struct phy_device *phydev)
> > +{
> > + return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0, 0,
> > + AT803X_DEBUG_RX_CLK_DLY_EN);
> > +}
> > +
> > +static inline int at803x_enable_tx_delay(struct phy_device *phydev)
> > +{
> > + return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_5, 0,
> > + AT803X_DEBUG_TX_CLK_DLY_EN);
> > +}
> > +
>
> Please do not use the inline directive in foo.c files, let the compiler
> decide.
Sure, this was in existing code, will fix up current occurrences as well.
Thanks
--
~Vinod
^ permalink raw reply
* [net, PATCH v2] net: stmmac: handle endianness in dwmac4_get_timestamp
From: Alexandre Torgue @ 2019-02-15 9:49 UTC (permalink / raw)
To: Giuseppe Cavallaro, Jose Abreu, davem
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel,
Alexandre Torgue, f.fainelli
GMAC IP is little-endian and used on several kind of CPU (big or little
endian). Main callbacks functions of the stmmac drivers take care about
it. It was not the case for dwmac4_get_timestamp function.
Fixes: ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
---
changes since V1:
-consider this patch as a fix
-change targeted tree from net-next to net
regards
Alex
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 20299f6..736e296 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -241,15 +241,18 @@ static inline void dwmac4_get_timestamp(void *desc, u32 ats, u64 *ts)
static int dwmac4_rx_check_timestamp(void *desc)
{
struct dma_desc *p = (struct dma_desc *)desc;
+ unsigned int rdes0 = le32_to_cpu(p->des0);
+ unsigned int rdes1 = le32_to_cpu(p->des1);
+ unsigned int rdes3 = le32_to_cpu(p->des3);
u32 own, ctxt;
int ret = 1;
- own = p->des3 & RDES3_OWN;
- ctxt = ((p->des3 & RDES3_CONTEXT_DESCRIPTOR)
+ own = rdes3 & RDES3_OWN;
+ ctxt = ((rdes3 & RDES3_CONTEXT_DESCRIPTOR)
>> RDES3_CONTEXT_DESCRIPTOR_SHIFT);
if (likely(!own && ctxt)) {
- if ((p->des0 == 0xffffffff) && (p->des1 == 0xffffffff))
+ if ((rdes0 == 0xffffffff) && (rdes1 == 0xffffffff))
/* Corrupted value */
ret = -EINVAL;
else
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] iptunnel: NULL pointer deref for ip_md_tunnel_xmit
From: Alan Maguire @ 2019-02-15 9:38 UTC (permalink / raw)
To: davem
Cc: naresh.kamboju, kuznet, yoshfuji, ast, daniel, kafai,
songliubraving, yhs, netdev
Naresh Kamboju noted the following oops during execution of selftest
tools/testing/selftests/bpf/test_tunnel.sh on x86_64:
[ 274.120445] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000000
[ 274.128285] #PF error: [INSTR]
[ 274.131351] PGD 8000000414a0e067 P4D 8000000414a0e067 PUD 3b6334067 PMD 0
[ 274.138241] Oops: 0010 [#1] SMP PTI
[ 274.141734] CPU: 1 PID: 11464 Comm: ping Not tainted
5.0.0-rc4-next-20190129 #1
[ 274.149046] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 274.156526] RIP: 0010: (null)
[ 274.160280] Code: Bad RIP value.
[ 274.163509] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
[ 274.168726] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
[ 274.175851] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
[ 274.182974] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
[ 274.190098] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
[ 274.197222] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
[ 274.204346] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
knlGS:0000000000000000
[ 274.212424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 274.218162] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
[ 274.225292] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 274.232416] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 274.239541] Call Trace:
[ 274.241988] ? tnl_update_pmtu+0x296/0x3b0
[ 274.246085] ip_md_tunnel_xmit+0x1bc/0x520
[ 274.250176] gre_fb_xmit+0x330/0x390
[ 274.253754] gre_tap_xmit+0x128/0x180
[ 274.257414] dev_hard_start_xmit+0xb7/0x300
[ 274.261598] sch_direct_xmit+0xf6/0x290
[ 274.265430] __qdisc_run+0x15d/0x5e0
[ 274.269007] __dev_queue_xmit+0x2c5/0xc00
[ 274.273011] ? dev_queue_xmit+0x10/0x20
[ 274.276842] ? eth_header+0x2b/0xc0
[ 274.280326] dev_queue_xmit+0x10/0x20
[ 274.283984] ? dev_queue_xmit+0x10/0x20
[ 274.287813] arp_xmit+0x1a/0xf0
[ 274.290952] arp_send_dst.part.19+0x46/0x60
[ 274.295138] arp_solicit+0x177/0x6b0
[ 274.298708] ? mod_timer+0x18e/0x440
[ 274.302281] neigh_probe+0x57/0x70
[ 274.305684] __neigh_event_send+0x197/0x2d0
[ 274.309862] neigh_resolve_output+0x18c/0x210
[ 274.314212] ip_finish_output2+0x257/0x690
[ 274.318304] ip_finish_output+0x219/0x340
[ 274.322314] ? ip_finish_output+0x219/0x340
[ 274.326493] ip_output+0x76/0x240
[ 274.329805] ? ip_fragment.constprop.53+0x80/0x80
[ 274.334510] ip_local_out+0x3f/0x70
[ 274.337992] ip_send_skb+0x19/0x40
[ 274.341391] ip_push_pending_frames+0x33/0x40
[ 274.345740] raw_sendmsg+0xc15/0x11d0
[ 274.349403] ? __might_fault+0x85/0x90
[ 274.353151] ? _copy_from_user+0x6b/0xa0
[ 274.357070] ? rw_copy_check_uvector+0x54/0x130
[ 274.361604] inet_sendmsg+0x42/0x1c0
[ 274.365179] ? inet_sendmsg+0x42/0x1c0
[ 274.368937] sock_sendmsg+0x3e/0x50
[ 274.372460] ___sys_sendmsg+0x26f/0x2d0
[ 274.376293] ? lock_acquire+0x95/0x190
[ 274.380043] ? __handle_mm_fault+0x7ce/0xb70
[ 274.384307] ? lock_acquire+0x95/0x190
[ 274.388053] ? __audit_syscall_entry+0xdd/0x130
[ 274.392586] ? ktime_get_coarse_real_ts64+0x64/0xc0
[ 274.397461] ? __audit_syscall_entry+0xdd/0x130
[ 274.401989] ? trace_hardirqs_on+0x4c/0x100
[ 274.406173] __sys_sendmsg+0x63/0xa0
[ 274.409744] ? __sys_sendmsg+0x63/0xa0
[ 274.413488] __x64_sys_sendmsg+0x1f/0x30
[ 274.417405] do_syscall_64+0x55/0x190
[ 274.421064] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 274.426113] RIP: 0033:0x7ff4ae0e6e87
[ 274.429686] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00
00 00 00 8b 05 ca d9 2b 00 48 63 d2 48 63 ff 85 c0 75 10 b8 2e 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 53 48 89 f3 48 83 ec 10 48 89 7c
24 08
[ 274.448422] RSP: 002b:00007ffcd9b76db8 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[ 274.455978] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007ff4ae0e6e87
[ 274.463104] RDX: 0000000000000000 RSI: 00000000006092e0 RDI: 0000000000000003
[ 274.470228] RBP: 0000000000000000 R08: 00007ffcd9bc40a0 R09: 00007ffcd9bc4080
[ 274.477349] R10: 000000000000060a R11: 0000000000000246 R12: 0000000000000003
[ 274.484475] R13: 0000000000000016 R14: 00007ffcd9b77fa0 R15: 00007ffcd9b78da4
[ 274.491602] Modules linked in: cls_bpf sch_ingress iptable_filter
ip_tables algif_hash af_alg x86_pkg_temp_thermal fuse [last unloaded:
test_bpf]
[ 274.504634] CR2: 0000000000000000
[ 274.507976] ---[ end trace 196d18386545eae1 ]---
[ 274.512588] RIP: 0010: (null)
[ 274.516334] Code: Bad RIP value.
[ 274.519557] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
[ 274.524775] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
[ 274.531921] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
[ 274.539082] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
[ 274.546205] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
[ 274.553329] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
[ 274.560456] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
knlGS:0000000000000000
[ 274.568541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 274.574277] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
[ 274.581403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 274.588535] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 274.595658] Kernel panic - not syncing: Fatal exception in interrupt
[ 274.602046] Kernel Offset: 0x14400000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 274.612827] ---[ end Kernel panic - not syncing: Fatal exception in
interrupt ]---
[ 274.620387] ------------[ cut here ]------------
I'm also seeing the same failure on x86_64, and it reproduces
consistently.
From poking around it looks like the skb's dst entry is being used
to calculate the mtu in:
mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
...but because that dst_entry has an "ops" value set to md_dst_ops,
the various ops (including mtu) are not set:
crash> struct sk_buff._skb_refdst ffff928f87447700 -x
_skb_refdst = 0xffffcd6fbf5ea590
crash> struct dst_entry.ops 0xffffcd6fbf5ea590
ops = 0xffffffffa0193800
crash> struct dst_ops.mtu 0xffffffffa0193800
mtu = 0x0
crash>
I confirmed that the dst entry also has dst->input set to
dst_md_discard, so it looks like it's an entry that's been
initialized via __metadata_dst_init alright.
I think the fix here is to use skb_valid_dst(skb) - it checks
for DST_METADATA also, and with that fix in place, the
problem - which was previously 100% reproducible - disappears.
The below patch resolves the panic and all bpf tunnel tests pass
without incident.
Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
net/ipv4/ip_tunnel.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 893f013..5dcf50c 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -515,9 +515,10 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
mtu = dst_mtu(&rt->dst) - dev->hard_header_len
- sizeof(struct iphdr) - tunnel_hlen;
else
- mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
+ mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
- skb_dst_update_pmtu(skb, mtu);
+ if (skb_valid_dst(skb))
+ skb_dst_update_pmtu(skb, mtu);
if (skb->protocol == htons(ETH_P_IP)) {
if (!skb_is_gso(skb) &&
@@ -530,9 +531,11 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
}
#if IS_ENABLED(CONFIG_IPV6)
else if (skb->protocol == htons(ETH_P_IPV6)) {
- struct rt6_info *rt6 = (struct rt6_info *)skb_dst(skb);
+ struct rt6_info *rt6;
__be32 daddr;
+ rt6 = skb_valid_dst(skb) ? (struct rt6_info *)skb_dst(skb) :
+ NULL;
daddr = md ? dst : tunnel->parms.iph.daddr;
if (rt6 && mtu < dst_mtu(skb_dst(skb)) &&
--
1.8.3.1
^ permalink raw reply related
* Re: [net-next] net: stmmac: handle endianness in dwmac4_get_timestamp
From: Alexandre Torgue @ 2019-02-15 9:09 UTC (permalink / raw)
To: Florian Fainelli, Giuseppe Cavallaro, Jose Abreu, davem
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <59a381e6-02eb-3c97-bc63-5a8f511a1901@gmail.com>
On 2/14/19 7:09 PM, Florian Fainelli wrote:
> On 2/14/19 9:26 AM, Alexandre Torgue wrote:
>> GMAC IP is little-endian and used on several kind of CPU (big or little
>> endian). Main callbacks functions of the stmmac drivers take care about
>> it. It was not the case for dwmac4_get_timestamp function.
>
> This is clearly a bugfix, so you should be targeting the 'net' tree and
> provide a Fixes: tag so this can be backported to relevant stable kernels.
>
Ok Florian, I just have to find the right commit to fix :)
>>
>> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
>> index 20299f6..736e296 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
>> @@ -241,15 +241,18 @@ static inline void dwmac4_get_timestamp(void *desc, u32 ats, u64 *ts)
>> static int dwmac4_rx_check_timestamp(void *desc)
>> {
>> struct dma_desc *p = (struct dma_desc *)desc;
>> + unsigned int rdes0 = le32_to_cpu(p->des0);
>> + unsigned int rdes1 = le32_to_cpu(p->des1);
>> + unsigned int rdes3 = le32_to_cpu(p->des3);
>> u32 own, ctxt;
>> int ret = 1;
>>
>> - own = p->des3 & RDES3_OWN;
>> - ctxt = ((p->des3 & RDES3_CONTEXT_DESCRIPTOR)
>> + own = rdes3 & RDES3_OWN;
>> + ctxt = ((rdes3 & RDES3_CONTEXT_DESCRIPTOR)
>> >> RDES3_CONTEXT_DESCRIPTOR_SHIFT);
>>
>> if (likely(!own && ctxt)) {
>> - if ((p->des0 == 0xffffffff) && (p->des1 == 0xffffffff))
>> + if ((rdes0 == 0xffffffff) && (rdes1 == 0xffffffff))
>> /* Corrupted value */
>> ret = -EINVAL;
>> else
>>
>
>
^ permalink raw reply
* Re: [PATCH net-next 2/3] ethtool: add compat for flash update
From: Michal Kubecek @ 2019-02-15 8:53 UTC (permalink / raw)
To: netdev; +Cc: Jakub Kicinski, davem, jiri, oss-drivers, andrew
In-Reply-To: <20190214214046.19182-3-jakub.kicinski@netronome.com>
On Thu, Feb 14, 2019 at 01:40:45PM -0800, Jakub Kicinski wrote:
> If driver does not support ethtool flash update operation
> call into devlink.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
...
> diff --git a/net/core/devlink.c b/net/core/devlink.c
> index bd507e13bb7b..d169b5426d3d 100644
> --- a/net/core/devlink.c
> +++ b/net/core/devlink.c
> @@ -6435,6 +6435,36 @@ void devlink_compat_running_version(struct net_device *dev,
> mutex_unlock(&devlink_mutex);
> }
>
> +int devlink_compat_flash_update(struct net_device *dev, const char *file_name)
> +{
> + struct devlink_port *devlink_port;
> + struct devlink *devlink;
> +
> + 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);
> +
> + return -EOPNOTSUPP;
> +}
> +
> static int __init devlink_module_init(void)
> {
> return genl_register_family(&devlink_nl_family);
We already have similar lookup in devlink_compat_running_version() (the
only difference seems to be that we keep holding devlink_mutex until the
end there) and it's likely the net_device -> devlink lookup will be
needed in more places in the future. How about having a helper for it?
I also wonder how does the lookup scale. But I don't have clear idea
how long the lists can become in real life and the ethtool operations
are not really time critical.
Michal Kubecek
^ permalink raw reply
* [PATCH net-next] net: phy: marvell10g: Don't explicitly set Pause and Asym_Pause
From: Maxime Chevallier @ 2019-02-15 8:33 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Andrew Lunn,
Florian Fainelli, Heiner Kallweit, Russell King, linux-arm-kernel,
Antoine Tenart, thomas.petazzoni, gregory.clement, miquel.raynal
The PHY core expects PHY drivers not to set Pause and Asym_Pause bits,
unless the driver only wants to specify one of them due to HW
limitation. In the case of the Marvell10g driver, we don't need to set
them.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/marvell10g.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 496805c0ddfe..c04fe5a75129 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -242,9 +242,6 @@ static int mv3310_config_init(struct phy_device *phydev)
phydev->interface != PHY_INTERFACE_MODE_10GKR)
return -ENODEV;
- __set_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydev->supported);
- __set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydev->supported);
-
if (phydev->c45_ids.devices_in_package & MDIO_DEVS_AN) {
val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_STAT1);
if (val < 0)
--
2.19.2
^ permalink raw reply related
* [PATCH] net: dsa: Implement flow_dissect callback for tag_dsa.
From: Rundong Ge @ 2019-02-15 8:22 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, f.fainelli, davem, netdev, linux-kernel, rdong.ge
RPS not work for DSA devices since the 'skb_get_hash'
will always get the invalid hash for dsa tagged packets.
"[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
introduced the flow_dissect callback to get the right hash for
MTK tagged packet. And tag_dsa also needs to implement
the callback.
Signed-off-by: Rundong Ge <rdong.ge@gmail.com>
---
net/dsa/tag_dsa.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c
index 8b2f92e..67ff3fa 100644
--- a/net/dsa/tag_dsa.c
+++ b/net/dsa/tag_dsa.c
@@ -146,8 +146,17 @@ static struct sk_buff *dsa_rcv(struct sk_buff *skb, struct net_device *dev,
return skb;
}
+static int dsa_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
+ int *offset)
+{
+ *offset = 4;
+ *proto = ((__be16 *)skb->data)[1];
+ return 0;
+}
+
const struct dsa_device_ops dsa_netdev_ops = {
.xmit = dsa_xmit,
.rcv = dsa_rcv,
+ .flow_dissect = dsa_tag_flow_dissect,
.overhead = DSA_HLEN,
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
From: Jason Wang @ 2019-02-15 7:53 UTC (permalink / raw)
To: mst, jasowang; +Cc: kvm, virtualization, netdev, linux-kernel, stephen
When fail, translate_desc() returns negative value, otherwise the
number of iovs. So we should fail when the return value is negative
instead of a blindly check against zero.
Reported-by: Stephen Hemminger <stephen@networkplumber.org>
Fixes: cc5e71075947 ("vhost: log dirty page correctly")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 24a129fcdd61..a2e5dc7716e2 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64 used_offset, u64 len)
ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
len, iov, 64, VHOST_ACCESS_WO);
- if (ret)
+ if (ret < 0)
return ret;
for (i = 0; i < ret; i++) {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 5/9] perf, bpf: save bpf_prog_info in a rbtree in perf_env
From: Jiri Olsa @ 2019-02-15 7:41 UTC (permalink / raw)
To: Song Liu
Cc: Netdev, linux-kernel, ast@kernel.org, daniel@iogearbox.net,
Kernel Team, peterz@infradead.org, acme@redhat.com
In-Reply-To: <2446DEFA-3CD3-4D3A-BE73-C29037F00C5C@fb.com>
On Thu, Feb 14, 2019 at 05:03:03PM +0000, Song Liu wrote:
>
>
> > On Feb 14, 2019, at 4:33 AM, Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Fri, Feb 08, 2019 at 05:17:01PM -0800, Song Liu wrote:
> >> bpf_prog_info contains information necessary to annotate bpf programs.
> >> This patch saves bpf_prog_info for bpf programs loaded in the system.
> >>
> >> perf-record saves bpf_prog_info information as headers to perf.data.
> >> A new header type HEADER_BPF_PROG_INFO is introduced for this data.
> >
> > please move those 2 changes into separate patches then
>
> Do you mean one patch to save data in rbtree, then a separate patch
> to save data in perf.data file?
yes
jirka
^ 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