* Re: [PATCH net] net: dsa: mv88e6xxx: Fix opps when adding vlan bridge
From: Andrew Lunn @ 2016-12-12 13:04 UTC (permalink / raw)
To: Vivien Didelot; +Cc: David Miller, netdev
In-Reply-To: <87a8c2w55e.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Sun, Dec 11, 2016 at 04:02:37PM -0500, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > @@ -1804,6 +1807,9 @@ static int mv88e6xxx_port_check_hw_vlan(struct dsa_switch *ds, int port,
> > chip->ports[port].bridge_dev)
> > break; /* same bridge, check next VLAN */
> >
> > + if (!chip->ports[i].bridge_dev)
> > + continue;
> > +
>
> The above truncated test:
>
> if (chip->ports[i].bridge_dev ==
> chip->ports[port].bridge_dev)
> break; /* same bridge, check next VLAN */
>
> should handle the case where bridge_dev is NULL, but if you want to
> explicitly test it, I'd move it before this statement.
>
> > netdev_warn(ds->ports[port].netdev,
> > "hardware VLAN %d already used by %s\n",
> > vlan.vid,
Hi Vivien
I don't think you comment is correct. Here is the loop, with my two
additions.
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i) {
if (dsa_is_dsa_port(ds, i) || dsa_is_cpu_port(ds, i))
continue;
if (!ds->ports[port].netdev)
continue;
if (vlan.data[i] ==
GLOBAL_VTU_DATA_MEMBER_TAG_NON_MEMBER)
continue;
if (chip->ports[i].bridge_dev ==
chip->ports[port].bridge_dev)
break; /* same bridge, check next VLAN */
if (!chip->ports[i].bridge_dev)
continue;
netdev_warn(ds->ports[port].netdev,
"hardware VLAN %d already used by %s\n",
vlan.vid,
netdev_name(chip->ports[i].bridge_dev));
err = -EOPNOTSUPP;
goto unlock;
}
The opps was occurring in netdev_name(). I did not check which
one. The obvious one, or the netdev_warn(netdev,... one.
> The above truncated test:
>
> if (chip->ports[i].bridge_dev ==
> chip->ports[port].bridge_dev)
> break; /* same bridge, check next VLAN */
>
> should handle the case where bridge_dev is NULL, but if you want to
> explicitly test it, I'd move it before this statement.
This will not stop chip->ports[i].bridge_dev == NULL from reaching the
netdev_warn().
Andrew
^ permalink raw reply
* Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def
From: Leon Romanovsky @ 2016-12-12 12:39 UTC (permalink / raw)
To: Ozgur Karatas; +Cc: yishaih, netdev, linux-kernel
In-Reply-To: <811031481540339@web1j.yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
On Mon, Dec 12, 2016 at 12:58:59PM +0200, Ozgur Karatas wrote:
> Hello all,
> I think should be use to "WARN_ON" and checkpatch script give to error, I fixed and I think should don't use "BUG_ON".
> Regards,
>
> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
NAK, Leon Romanovsky <leonro@mellanox.com>
If we put aside commit message issue, which was pointed to you by Stefan, your
proposed change is incorrect. By chnaging BUG_ONs to be WARN_ONs, you
will left the driver in improper state.
Thanks
> ---
> drivers/net/ethernet/mellanox/mlx4/icm.c | 4 ++--
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index 2a9dd46..3fde535 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, struct scatterlist *mem,
> return -ENOMEM;
>
> sg_set_buf(mem, buf, PAGE_SIZE << order);
> - BUG_ON(mem->offset);
> + WARN_ON(mem->offset);
> sg_dma_len(mem) = PAGE_SIZE << order;
> return 0;
> }
> @@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int npages,
> int ret;
>
> /* We use sg_set_buf for coherent allocs, which assumes low memory */
> - BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
> + WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>
> icm = kmalloc_node(sizeof(*icm),
> gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
> --
> 2.1.4
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v4 4/4] vsock: cancel packets when failing to connect
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Jorgen Hansen, kvm, virtualization, Stefan Hajnoczi
In-Reply-To: <1481545269-18104-4-git-send-email-bergwolf@gmail.com>
Otherwise we'll leave the packets queued until releasing vsock device.
E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest
will get the connect requests from failed host sockets.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
net/vmw_vsock/af_vsock.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 8a398b3..c73b03a 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1101,10 +1101,19 @@ static const struct proto_ops vsock_dgram_ops = {
.sendpage = sock_no_sendpage,
};
+static int vsock_transport_cancel_pkt(struct vsock_sock *vsk)
+{
+ if (!transport->cancel_pkt)
+ return -EOPNOTSUPP;
+
+ return transport->cancel_pkt(vsk);
+}
+
static void vsock_connect_timeout(struct work_struct *work)
{
struct sock *sk;
struct vsock_sock *vsk;
+ int cancel = 0;
vsk = container_of(work, struct vsock_sock, dwork.work);
sk = sk_vsock(vsk);
@@ -1115,8 +1124,11 @@ static void vsock_connect_timeout(struct work_struct *work)
sk->sk_state = SS_UNCONNECTED;
sk->sk_err = ETIMEDOUT;
sk->sk_error_report(sk);
+ cancel = 1;
}
release_sock(sk);
+ if (cancel)
+ vsock_transport_cancel_pkt(vsk);
sock_put(sk);
}
@@ -1223,11 +1235,13 @@ static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
err = sock_intr_errno(timeout);
sk->sk_state = SS_UNCONNECTED;
sock->state = SS_UNCONNECTED;
+ vsock_transport_cancel_pkt(vsk);
goto out_wait;
} else if (timeout == 0) {
err = -ETIMEDOUT;
sk->sk_state = SS_UNCONNECTED;
sock->state = SS_UNCONNECTED;
+ vsock_transport_cancel_pkt(vsk);
goto out_wait;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/4] vsock: add pkt cancel capability
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Jorgen Hansen, kvm, virtualization, Stefan Hajnoczi
In-Reply-To: <1481545269-18104-3-git-send-email-bergwolf@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
net/vmw_vsock/virtio_transport.c | 42 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 936d7ee..b7b78ce 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -170,6 +170,47 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt)
return len;
}
+static int
+virtio_transport_cancel_pkt(struct vsock_sock *vsk)
+{
+ struct virtio_vsock *vsock;
+ struct virtio_vsock_pkt *pkt, *n;
+ int cnt = 0;
+ LIST_HEAD(freeme);
+
+ vsock = virtio_vsock_get();
+ if (!vsock) {
+ return -ENODEV;
+ }
+
+ spin_lock_bh(&vsock->send_pkt_list_lock);
+ list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
+ if (pkt->cancel_token != vsk)
+ continue;
+ list_move(&pkt->list, &freeme);
+ }
+ spin_unlock_bh(&vsock->send_pkt_list_lock);
+
+ list_for_each_entry_safe(pkt, n, &freeme, list) {
+ if (pkt->reply)
+ cnt++;
+ list_del(&pkt->list);
+ virtio_transport_free_pkt(pkt);
+ }
+
+ if (cnt) {
+ struct virtqueue *rx_vq = vsock->vqs[VSOCK_VQ_RX];
+ int new_cnt;
+
+ new_cnt = atomic_sub_return(cnt, &vsock->queued_replies);
+ if (new_cnt + cnt >= virtqueue_get_vring_size(rx_vq) &&
+ new_cnt < virtqueue_get_vring_size(rx_vq))
+ queue_work(virtio_vsock_workqueue, &vsock->rx_work);
+ }
+
+ return 0;
+}
+
static void virtio_vsock_rx_fill(struct virtio_vsock *vsock)
{
int buf_len = VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE;
@@ -419,6 +460,7 @@ static struct virtio_transport virtio_transport = {
.release = virtio_transport_release,
.connect = virtio_transport_connect,
.shutdown = virtio_transport_shutdown,
+ .cancel_pkt = virtio_transport_cancel_pkt,
.dgram_bind = virtio_transport_dgram_bind,
.dgram_dequeue = virtio_transport_dgram_dequeue,
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/4] vhost-vsock: add pkt cancel capability
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Stefan Hajnoczi, David Miller, Jorgen Hansen, kvm
In-Reply-To: <1481545269-18104-2-git-send-email-bergwolf@gmail.com>
To allow canceling all packets of a connection.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
drivers/vhost/vsock.c | 41 +++++++++++++++++++++++++++++++++++++++++
include/net/af_vsock.h | 3 +++
2 files changed, 44 insertions(+)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index a504e2e0..fef8808 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -218,6 +218,46 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt)
return len;
}
+static int
+vhost_transport_cancel_pkt(struct vsock_sock *vsk)
+{
+ struct vhost_vsock *vsock;
+ struct virtio_vsock_pkt *pkt, *n;
+ int cnt = 0;
+ LIST_HEAD(freeme);
+
+ /* Find the vhost_vsock according to guest context id */
+ vsock = vhost_vsock_get(vsk->remote_addr.svm_cid);
+ if (!vsock)
+ return -ENODEV;
+
+ spin_lock_bh(&vsock->send_pkt_list_lock);
+ list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
+ if (pkt->cancel_token != vsk)
+ continue;
+ list_move(&pkt->list, &freeme);
+ }
+ spin_unlock_bh(&vsock->send_pkt_list_lock);
+
+ list_for_each_entry_safe(pkt, n, &freeme, list) {
+ if (pkt->reply)
+ cnt++;
+ list_del(&pkt->list);
+ virtio_transport_free_pkt(pkt);
+ }
+
+ if (cnt) {
+ struct vhost_virtqueue *tx_vq = &vsock->vqs[VSOCK_VQ_TX];
+ int new_cnt;
+
+ new_cnt = atomic_sub_return(cnt, &vsock->queued_replies);
+ if (new_cnt + cnt >= tx_vq->num && new_cnt < tx_vq->num)
+ vhost_poll_queue(&tx_vq->poll);
+ }
+
+ return 0;
+}
+
static struct virtio_vsock_pkt *
vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
unsigned int out, unsigned int in)
@@ -664,6 +704,7 @@ static struct virtio_transport vhost_transport = {
.release = virtio_transport_release,
.connect = virtio_transport_connect,
.shutdown = virtio_transport_shutdown,
+ .cancel_pkt = vhost_transport_cancel_pkt,
.dgram_enqueue = virtio_transport_dgram_enqueue,
.dgram_dequeue = virtio_transport_dgram_dequeue,
diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index f275896..f32ed9a 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -100,6 +100,9 @@ struct vsock_transport {
void (*destruct)(struct vsock_sock *);
void (*release)(struct vsock_sock *);
+ /* Cancel all pending packets sent on vsock. */
+ int (*cancel_pkt)(struct vsock_sock *vsk);
+
/* Connections. */
int (*connect)(struct vsock_sock *);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/4] vsock: track pkt owner vsock
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Stefan Hajnoczi, David Miller, Jorgen Hansen, kvm
In-Reply-To: <1481545269-18104-1-git-send-email-bergwolf@gmail.com>
So that we can cancel a queued pkt later if necessary.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
include/linux/virtio_vsock.h | 2 ++
net/vmw_vsock/virtio_transport_common.c | 7 +++++++
2 files changed, 9 insertions(+)
diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
index 9638bfe..193ad3a 100644
--- a/include/linux/virtio_vsock.h
+++ b/include/linux/virtio_vsock.h
@@ -48,6 +48,7 @@ struct virtio_vsock_pkt {
struct virtio_vsock_hdr hdr;
struct work_struct work;
struct list_head list;
+ void *cancel_token; /* only used for cancellation */
void *buf;
u32 len;
u32 off;
@@ -56,6 +57,7 @@ struct virtio_vsock_pkt {
struct virtio_vsock_pkt_info {
u32 remote_cid, remote_port;
+ struct vsock_sock *vsk;
struct msghdr *msg;
u32 pkt_len;
u16 type;
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index a53b3a1..ef94eb8 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -57,6 +57,7 @@ virtio_transport_alloc_pkt(struct virtio_vsock_pkt_info *info,
pkt->len = len;
pkt->hdr.len = cpu_to_le32(len);
pkt->reply = info->reply;
+ pkt->cancel_token = info->vsk;
if (info->msg && len > 0) {
pkt->buf = kmalloc(len, GFP_KERNEL);
@@ -180,6 +181,7 @@ static int virtio_transport_send_credit_update(struct vsock_sock *vsk,
struct virtio_vsock_pkt_info info = {
.op = VIRTIO_VSOCK_OP_CREDIT_UPDATE,
.type = type,
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
@@ -519,6 +521,7 @@ int virtio_transport_connect(struct vsock_sock *vsk)
struct virtio_vsock_pkt_info info = {
.op = VIRTIO_VSOCK_OP_REQUEST,
.type = VIRTIO_VSOCK_TYPE_STREAM,
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
@@ -534,6 +537,7 @@ int virtio_transport_shutdown(struct vsock_sock *vsk, int mode)
VIRTIO_VSOCK_SHUTDOWN_RCV : 0) |
(mode & SEND_SHUTDOWN ?
VIRTIO_VSOCK_SHUTDOWN_SEND : 0),
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
@@ -560,6 +564,7 @@ virtio_transport_stream_enqueue(struct vsock_sock *vsk,
.type = VIRTIO_VSOCK_TYPE_STREAM,
.msg = msg,
.pkt_len = len,
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
@@ -581,6 +586,7 @@ static int virtio_transport_reset(struct vsock_sock *vsk,
.op = VIRTIO_VSOCK_OP_RST,
.type = VIRTIO_VSOCK_TYPE_STREAM,
.reply = !!pkt,
+ .vsk = vsk,
};
/* Send RST only if the original pkt is not a RST pkt */
@@ -826,6 +832,7 @@ virtio_transport_send_response(struct vsock_sock *vsk,
.remote_cid = le32_to_cpu(pkt->hdr.src_cid),
.remote_port = le32_to_cpu(pkt->hdr.src_port),
.reply = true,
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/4] vsock: cancel connect packets when failing to connect
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Stefan Hajnoczi, David Miller, Jorgen Hansen, kvm
Currently, if a connect call fails on a signal or timeout (e.g., guest is still
in the process of starting up), we'll just return to caller and leave the connect
packet queued and they are sent even though the connection is considered a failure,
which can confuse applications with unwanted false connect attempt.
The patchset enables vsock (both host and guest) to cancel queued packets when
a connect attempt is considered to fail.
v4 changelog:
- drop two unnecessary void * cast
- update new callback commnet
v3 changelog:
- define cancel_pkt callback in struct vsock_transport rather than struct virtio_transport
- rename virtio_vsock_pkt->vsk to virtio_vsock_pkt->cancel_token
v2 changelog:
- fix queued_replies counting and resume tx/rx when necessary
Cheers,
Tao
Peng Tao (4):
vsock: track pkt owner vsock
vhost-vsock: add pkt cancel capability
vsock: add pkt cancel capability
vsock: cancel packets when failing to connect
drivers/vhost/vsock.c | 41 ++++++++++++++++++++++++++++++++
include/linux/virtio_vsock.h | 2 ++
include/net/af_vsock.h | 3 +++
net/vmw_vsock/af_vsock.c | 14 +++++++++++
net/vmw_vsock/virtio_transport.c | 42 +++++++++++++++++++++++++++++++++
net/vmw_vsock/virtio_transport_common.c | 7 ++++++
6 files changed, 109 insertions(+)
--
2.7.4
^ permalink raw reply
* (unknown),
From: Brianna Falzone @ 2016-12-12 12:19 UTC (permalink / raw)
My name is Brianna Falzone , I am a United State Army officer, i saw
your mail on google search please reply to me So that we know better.
I hope to read
Thanks and hope to hear from you soon.
Regards
Brianna
^ permalink raw reply
* Re: Re: stmmac driver...
From: Niklas Cassel @ 2016-12-12 12:14 UTC (permalink / raw)
To: Jie Deng, Niklas Cassel
Cc: David Miller, alexandre.torgue, peppe.cavallaro, netdev,
CARLOS.PALMINHA, Joao.Pinto
In-Reply-To: <f64fde7c-9fe5-7ed9-8d01-23702e64f8aa@synopsys.com>
(resend with netdev included)
On 12/09/2016 05:29 PM, Jie Deng wrote:
>
> On 2016/12/9 18:50, Niklas Cassel wrote:
>> Hello Jie Deng
>>
>>
>> In your cover letter you wrote
>>
>> dwc-eth-xxx.x
>> The DWC ethernet core layer (DWC ECL). This layer contains codes
>> can be shared by different DWC series ethernet cores
>>
>> Does this mean that code in dwc-eth-xxx.x is common to all
>> the different Synopsys IPs, GMAC, XGMAC and XLGMAC ?
>>
>>
>> Regards,
>> Niklas
> Yeah, these codes may be reused in the future (due to HW similarities) but it
> would require a lot of refactoring. For the moment I will focus on the driver
> only for XLGMAC.
Ok, thank you for the clarification.
>
> XLGMAC is Synopsys "Enterprise MAC" controller (the product is already public):
> https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_enterprise_mac
>
> What do you think following strategy:
> - GMAC (QoS): discard drivers/net/ethernet/synopsys/dwc_eth_qos.c and keep
> development under drivers/net/ethernet/stmicro/stmmac/
> - XGMAC: keep development under drivers/net/ethernet/amd/xgbe/
> - XLGMAC: do development under drivers/net/ethernet/synopsys/
I don't have an opinion regarding XLGMAC.
For GMAC, I think it's a good idea that everybody focuses on the same driver (stmmac).
The same thing applies to XGMAC, amd-xgbe and sxgbe, however there I don't know
of any consolidation efforts.
>
> Thanks,
> Jie
>
>> On Fri, Dec 9, 2016 at 11:05 AM, Jie Deng <Jie.Deng1@synopsys.com> wrote:
>>> On 2016/12/8 23:25, David Miller wrote:
>>>> From: Alexandre Torgue <alexandre.torgue@st.com>
>>>> Date: Thu, 8 Dec 2016 14:55:04 +0100
>>>>
>>>>> Maybe I forget some series. Do you have others in mind ?
>>>> Please see the thread titled:
>>>>
>>>> "net: ethernet: Initial driver for Synopsys DWC XLGMAC"
>>>>
>>>> which seems to be discussing consolidation of various drivers
>>>> for the same IP core, of which stmmac is one.
>>>>
>>>> I personally am against any change of the driver name and
>>>> things like this, and wish the people doing that work would
>>>> simply contribute to making whatever changes they need directly
>>>> to the stmmac driver.
>>>>
>>>> You really need to voice your opinion when major changes are being
>>>> proposed for the driver you maintain.
>>>>
>>> Hi David and Alex,
>>>
>>> XLGMAC is not a version of GMAC. Synopsys has several IPs and each IP has
>>> several versions.
>>>
>>> GMAC(QoS): 3.5, 3.7, 4.0, 4.10, 4.20...
>>> XGMAC: 1.00, 1.10, 1.20, 2.00, 2.10, 2.11...
>>> XLGMAC (Synopsys DesignWare Core Enterprise Ethernet): this is a new IP.
>>>
>>> Regards,
>>> Jie
>>>
>
^ permalink raw reply
* [PATCH 1/2] net: ethernet: hisi_femac: Call SET_NETDEV_DEV()
From: Dongpo Li @ 2016-12-12 12:03 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, davem
Cc: f.fainelli, xuejiancheng, benjamin.chenhao, caizhiyong, netdev,
linux-kernel, Dongpo Li
In-Reply-To: <1481544223-207906-1-git-send-email-lidongpo@hisilicon.com>
The hisi_femac driver calls into PHYLIB which now checks for
net_device->dev.parent, so make sure we do set it before calling into
any MDIO/PHYLIB related function.
Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner")
Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hisi_femac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hisi_femac.c b/drivers/net/ethernet/hisilicon/hisi_femac.c
index 4986306..979852d 100644
--- a/drivers/net/ethernet/hisilicon/hisi_femac.c
+++ b/drivers/net/ethernet/hisilicon/hisi_femac.c
@@ -805,6 +805,7 @@ static int hisi_femac_drv_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, ndev);
+ SET_NETDEV_DEV(ndev, &pdev->dev);
priv = netdev_priv(ndev);
priv->dev = dev;
@@ -882,7 +883,6 @@ static int hisi_femac_drv_probe(struct platform_device *pdev)
ndev->netdev_ops = &hisi_femac_netdev_ops;
ndev->ethtool_ops = &hisi_femac_ethtools_ops;
netif_napi_add(ndev, &priv->napi, hisi_femac_poll, FEMAC_POLL_WEIGHT);
- SET_NETDEV_DEV(ndev, &pdev->dev);
hisi_femac_port_init(priv);
--
2.8.2
^ permalink raw reply related
* [PATCH 2/2] net: ethernet: hip04: Call SET_NETDEV_DEV()
From: Dongpo Li @ 2016-12-12 12:03 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, davem
Cc: f.fainelli, xuejiancheng, benjamin.chenhao, caizhiyong, netdev,
linux-kernel, Dongpo Li
In-Reply-To: <1481544223-207906-1-git-send-email-lidongpo@hisilicon.com>
The hip04 driver calls into PHYLIB which now checks for
net_device->dev.parent, so make sure we do set it before calling into
any MDIO/PHYLIB related function.
Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner")
Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 854befd..97b1847 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -828,6 +828,7 @@ static int hip04_mac_probe(struct platform_device *pdev)
priv = netdev_priv(ndev);
priv->ndev = ndev;
platform_set_drvdata(pdev, ndev);
+ SET_NETDEV_DEV(ndev, &pdev->dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(d, res);
@@ -903,7 +904,6 @@ static int hip04_mac_probe(struct platform_device *pdev)
ndev->priv_flags |= IFF_UNICAST_FLT;
ndev->irq = irq;
netif_napi_add(ndev, &priv->napi, hip04_rx_poll, NAPI_POLL_WEIGHT);
- SET_NETDEV_DEV(ndev, &pdev->dev);
hip04_reset_ppe(priv);
if (priv->phy_mode == PHY_INTERFACE_MODE_MII)
--
2.8.2
^ permalink raw reply related
* [PATCH 0/2] net: ethernet: hisilicon: set dev->dev.parent before PHY connect
From: Dongpo Li @ 2016-12-12 12:03 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, davem
Cc: f.fainelli, xuejiancheng, benjamin.chenhao, caizhiyong, netdev,
linux-kernel, Dongpo Li
This patch series builds atop:
ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461 ("phy: Don't increment MDIO bus
refcount unless it's a different owner")
I have checked all the hisilicon ethernet driver and found only two drivers
need to be fixed to make sure set dev->dev.parent before PHY connect.
Dongpo Li (2):
net: ethernet: hisi_femac: Call SET_NETDEV_DEV()
net: ethernet: hip04: Call SET_NETDEV_DEV()
drivers/net/ethernet/hisilicon/hip04_eth.c | 2 +-
drivers/net/ethernet/hisilicon/hisi_femac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.8.2
^ permalink raw reply
* Re: [PATCH v3 2/4] vhost-vsock: add pkt cancel capability
From: Peng Tao @ 2016-12-12 11:56 UTC (permalink / raw)
To: Jorgen S. Hansen
Cc: netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
David Miller, Stefan Hajnoczi, kvm@vger.kernel.org
In-Reply-To: <426F96AC-2E7C-4BEC-A3D3-7D8A97FDD51D@vmware.com>
On Mon, Dec 12, 2016 at 6:37 PM, Jorgen S. Hansen <jhansen@vmware.com> wrote:
>
>> On Dec 8, 2016, at 6:12 PM, Peng Tao <bergwolf@gmail.com> wrote:
>>
>> --- a/include/net/af_vsock.h
>> +++ b/include/net/af_vsock.h
>> @@ -100,6 +100,9 @@ struct vsock_transport {
>> void (*destruct)(struct vsock_sock *);
>> void (*release)(struct vsock_sock *);
>>
>> + /* Cancel packets belonging the same vsock */
>
> How about “/* Cancel all pending packets sent on vsock. */“ ?
>
Sure. I'll update it.
Thanks,
Tao
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [iproute2 net-next 3/8] bpf: Add BPF_ macros
From: Daniel Borkmann @ 2016-12-12 11:48 UTC (permalink / raw)
To: Hannes Frederic Sowa, David Ahern, netdev, stephen
In-Reply-To: <88e7eece-be2a-3b11-3dc1-3afa7a9bb14a@stressinduktion.org>
On 12/12/2016 12:28 PM, Hannes Frederic Sowa wrote:
> On 12.12.2016 01:53, David Ahern wrote:
>> Based on version in kernel repo, samples/bpf/libbpf.h
>>
>> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
>> ---
>> include/bpf_util.h | 179 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 179 insertions(+)
>>
>> diff --git a/include/bpf_util.h b/include/bpf_util.h
>> index 726e34777755..5361dab1933d 100644
>
> Maybe this was already discussed: why are those not part of uapi? They
> get used in the bpf manpage.
The reason why these macros haven't been exposed to uapi header was because
they are not strict part of kernel abi. So really only the very minimum that
had to go there (such as insn opcodes) were placed into the header. That way,
kernel is still free to, for example, change or rename the macros once new
insns would get added, and user space can just define what it really needs.
That way, both don't get into each others way long term. Often it's also not
really needed if you have an elf loader, f.e. iproute2 could live without
them (up to this point).
Just took a look at the man page example, we don't even define BPF_CALL_FUNC()
in the kernel, so it's also not exactly the same. Probably makes sense to
fix/complete that example and in general add a description there wrt opcodes.
Last time I spoke with Michael, he planned to make a bigger revision to the
man page to improve documentation.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON
From: Ozgur Karatas @ 2016-12-12 11:32 UTC (permalink / raw)
To: Stefan Schmidt, yishaih@mellanox.com; +Cc: netdev, linux-kernel
In-Reply-To: <080dc5cc-3d72-a5db-2f53-5c6ce74837b4@osg.samsung.com>
Dear Stefan;
I'm reading to Documentation/SubmittingPatches and I still apologized for misrepresentations my patches.
I will add a next time good commit message and commit subjects.
Sorry,
Regards
Ozgur Karatas
12.12.2016, 13:20, "Stefan Schmidt" <stefan@osg.samsung.com>:
> Hello.
>
> On 12/12/16 11:58, Ozgur Karatas wrote:
>> Hello all,
>> I think should be use to "WARN_ON" and checkpatch script give to error, I fixed and I think should don't use "BUG_ON".
>> Regards,
>>
>> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
>
> I pointed you already before to the Documentation how to prepare a
> commit subject and commit message. You just replied with that you are
> new to contributing patches. That is all fine and many people are new
> each release. Please take the time to read the provided and pointed out
> docs.
>
> If you keep ignoring such suggestions and docs I would think people will
> keep ignoring your patches.
>
> regards
> Stefan Schmidt
^ permalink raw reply
* [patch net-next] irda: w83977af_ir: cleanup an indent issue
From: Dan Carpenter @ 2016-12-12 11:21 UTC (permalink / raw)
To: Samuel Ortiz, Joe Perches; +Cc: netdev, kernel-janitors
In commit 99d8d2159d7c ("irda: w83977af_ir: Neaten logging"), we
accidentally added an extra tab to these lines.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index f293d33fb28f..8d5b903d1d9d 100644
--- a/drivers/net/irda/w83977af_ir.c
+++ b/drivers/net/irda/w83977af_ir.c
@@ -517,9 +517,9 @@ static netdev_tx_t w83977af_hard_xmit(struct sk_buff *skb,
mtt = irda_get_mtt(skb);
pr_debug("%s: %ld, mtt=%d\n", __func__, jiffies, mtt);
- if (mtt > 1000)
- mdelay(mtt / 1000);
- else if (mtt)
+ if (mtt > 1000)
+ mdelay(mtt / 1000);
+ else if (mtt)
udelay(mtt);
/* Enable DMA interrupt */
^ permalink raw reply related
* Re: [iproute2 net-next 3/8] bpf: Add BPF_ macros
From: Hannes Frederic Sowa @ 2016-12-12 11:28 UTC (permalink / raw)
To: David Ahern, netdev, stephen
In-Reply-To: <1481503995-24825-4-git-send-email-dsa@cumulusnetworks.com>
On 12.12.2016 01:53, David Ahern wrote:
> Based on version in kernel repo, samples/bpf/libbpf.h
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> ---
> include/bpf_util.h | 179 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 179 insertions(+)
>
> diff --git a/include/bpf_util.h b/include/bpf_util.h
> index 726e34777755..5361dab1933d 100644
Maybe this was already discussed: why are those not part of uapi? They
get used in the bpf manpage.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def
From: Stefan Schmidt @ 2016-12-12 11:19 UTC (permalink / raw)
To: Ozgur Karatas, yishaih; +Cc: netdev, linux-kernel
In-Reply-To: <811031481540339@web1j.yandex.ru>
Hello.
On 12/12/16 11:58, Ozgur Karatas wrote:
> Hello all,
> I think should be use to "WARN_ON" and checkpatch script give to error, I fixed and I think should don't use "BUG_ON".
> Regards,
>
> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
I pointed you already before to the Documentation how to prepare a
commit subject and commit message. You just replied with that you are
new to contributing patches. That is all fine and many people are new
each release. Please take the time to read the provided and pointed out
docs.
If you keep ignoring such suggestions and docs I would think people will
keep ignoring your patches.
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Dongpo Li @ 2016-12-12 11:16 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland-5wv7dgnIgG8, mturquette-rdvid1DuHRBWk0Htik3J/w,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
arnd-r2nGTMty4D4, andrew-g2DYL2Zd6BY,
xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q,
benjamin.chenhao-C8/M+/jPZTeaMJb+Lgu22Q,
caizhiyong-C8/M+/jPZTeaMJb+Lgu22Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209223521.5dnj7l44e663sntl@rob-hp-laptop>
Hi Rob,
On 2016/12/10 6:35, Rob Herring wrote:
> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
>> The "hix5hd2" is SoC name, add the generic ethernet driver name.
>> The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds
>> the SG/TXCSUM/TSO/UFO features.
>>
>> Signed-off-by: Dongpo Li <lidongpo-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
>> ---
>> .../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt | 9 +++++++--
>> drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 15 +++++++++++----
>> 2 files changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>> index 75d398b..75920f0 100644
>> --- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>> +++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>> @@ -1,7 +1,12 @@
>> Hisilicon hix5hd2 gmac controller
>>
>> Required properties:
>> -- compatible: should be "hisilicon,hix5hd2-gmac".
>> +- compatible: should contain one of the following SoC strings:
>> + * "hisilicon,hix5hd2-gemac"
>> + * "hisilicon,hi3798cv200-gemac"
>> + and one of the following version string:
>> + * "hisilicon,hisi-gemac-v1"
>> + * "hisilicon,hisi-gemac-v2"
>
> What combinations are valid? I assume both chips don't have both v1 and
> v2. 2 SoCs and 2 versions so far, I don't think there is much point to
> have the v1 and v2 compatible strings.
>
The v1 and v2 are generic MAC compatible strings, many HiSilicon SoCs may
use the same MAC version. For example,
hix5hd2, hi3716cv200 SoCs use the v1 MAC version,
hi3798cv200, hi3516a SoCs use the v2 MAC version,
and there may be more SoCs added in future.
So I think the generic compatible strings are okay here.
Should I add the hi3716cv200, hi3516a SoCs compatible here?
Do you have any good advice?
>> - reg: specifies base physical address(s) and size of the device registers.
>> The first region is the MAC register base and size.
>> The second region is external interface control register.
>> @@ -20,7 +25,7 @@ Required properties:
>>
>> Example:
>> gmac0: ethernet@f9840000 {
>> - compatible = "hisilicon,hix5hd2-gmac";
>> + compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
>
> You can't just change compatible strings.
>
Okay, maybe I should name all the compatible string with the suffix "-gmac" instead of
"-gemac". This can keep the compatible strings with the same suffix. Is this okay?
Can I just add the generic compatible string without changing the SoCs compatible string?
Like following:
gmac0: ethernet@f9840000 {
- compatible = "hisilicon,hix5hd2-gmac";
+ compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
>> reg = <0xf9840000 0x1000>,<0xf984300c 0x4>;
>> interrupts = <0 71 4>;
>> #address-cells = <1>;
>
> .
>
Regards,
Dongpo
.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/1] Fixed to BUG_ON to WARN_ON def
From: Ozgur Karatas @ 2016-12-12 10:58 UTC (permalink / raw)
To: yishaih; +Cc: netdev, linux-kernel
Hello all,
I think should be use to "WARN_ON" and checkpatch script give to error, I fixed and I think should don't use "BUG_ON".
Regards,
Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
drivers/net/ethernet/mellanox/mlx4/icm.c | 4 ++--
diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c
index 2a9dd46..3fde535 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.c
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
@@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, struct scatterlist *mem,
return -ENOMEM;
sg_set_buf(mem, buf, PAGE_SIZE << order);
- BUG_ON(mem->offset);
+ WARN_ON(mem->offset);
sg_dma_len(mem) = PAGE_SIZE << order;
return 0;
}
@@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int npages,
int ret;
/* We use sg_set_buf for coherent allocs, which assumes low memory */
- BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
+ WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
icm = kmalloc_node(sizeof(*icm),
gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v3 4/4] vsock: cancel packets when failing to connect
From: Jorgen S. Hansen @ 2016-12-12 10:41 UTC (permalink / raw)
To: Peng Tao
Cc: netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
David Miller, Stefan Hajnoczi, kvm@vger.kernel.org
In-Reply-To: <1481217156-7160-5-git-send-email-bergwolf@gmail.com>
> On Dec 8, 2016, at 6:12 PM, Peng Tao <bergwolf@gmail.com> wrote:
>
> Otherwise we'll leave the packets queued until releasing vsock device.
> E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest
> will get the connect requests from failed host sockets.
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Peng Tao <bergwolf@gmail.com>
> ---
> net/vmw_vsock/af_vsock.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index 8a398b3..c73b03a 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -1101,10 +1101,19 @@ static const struct proto_ops vsock_dgram_ops = {
> .sendpage = sock_no_sendpage,
> };
>
> +static int vsock_transport_cancel_pkt(struct vsock_sock *vsk)
> +{
> + if (!transport->cancel_pkt)
> + return -EOPNOTSUPP;
> +
> + return transport->cancel_pkt(vsk);
> +}
> +
> static void vsock_connect_timeout(struct work_struct *work)
> {
> struct sock *sk;
> struct vsock_sock *vsk;
> + int cancel = 0;
>
> vsk = container_of(work, struct vsock_sock, dwork.work);
> sk = sk_vsock(vsk);
> @@ -1115,8 +1124,11 @@ static void vsock_connect_timeout(struct work_struct *work)
> sk->sk_state = SS_UNCONNECTED;
> sk->sk_err = ETIMEDOUT;
> sk->sk_error_report(sk);
> + cancel = 1;
> }
> release_sock(sk);
> + if (cancel)
> + vsock_transport_cancel_pkt(vsk);
>
> sock_put(sk);
> }
> @@ -1223,11 +1235,13 @@ static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
> err = sock_intr_errno(timeout);
> sk->sk_state = SS_UNCONNECTED;
> sock->state = SS_UNCONNECTED;
> + vsock_transport_cancel_pkt(vsk);
> goto out_wait;
> } else if (timeout == 0) {
> err = -ETIMEDOUT;
> sk->sk_state = SS_UNCONNECTED;
> sock->state = SS_UNCONNECTED;
> + vsock_transport_cancel_pkt(vsk);
> goto out_wait;
> }
>
> --
> 2.7.4
>
This looks fine to me:
Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
^ permalink raw reply
* Re: [PATCH v3 2/4] vhost-vsock: add pkt cancel capability
From: Jorgen S. Hansen @ 2016-12-12 10:37 UTC (permalink / raw)
To: Peng Tao
Cc: netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
David Miller, Stefan Hajnoczi, kvm@vger.kernel.org
In-Reply-To: <1481217156-7160-3-git-send-email-bergwolf@gmail.com>
> On Dec 8, 2016, at 6:12 PM, Peng Tao <bergwolf@gmail.com> wrote:
>
> --- a/include/net/af_vsock.h
> +++ b/include/net/af_vsock.h
> @@ -100,6 +100,9 @@ struct vsock_transport {
> void (*destruct)(struct vsock_sock *);
> void (*release)(struct vsock_sock *);
>
> + /* Cancel packets belonging the same vsock */
How about “/* Cancel all pending packets sent on vsock. */“ ?
> + int (*cancel_pkt)(struct vsock_sock *vsk);
> +
> /* Connections. */
> int (*connect)(struct vsock_sock *);
>
> --
> 2.7.4
>
Thanks,
Jørgen
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Harini Katakam @ 2016-12-12 10:34 UTC (permalink / raw)
To: Andrei Pistirica
Cc: Richard Cochran, Harini Katakam, Rafal Ozieblo, netdev,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, David Miller, Nicolas Ferre,
Punnaiah Choudary Kalluri, michals@xilinx.com, Anirudha Sarangi,
Boris Brezillon, alexandre.belloni, tbultel
In-Reply-To: <07C910AB6AC6C345A093D5A08F5AF568CB74D84D@CHN-SV-EXMX03.mchp-main.com>
Hi Andrei,
On Mon, Dec 12, 2016 at 3:52 PM, <Andrei.Pistirica@microchip.com> wrote:
>
>
>> -----Original Message-----
>> From: Rafal Ozieblo [mailto:rafalo@cadence.com]
>> Sent: Friday, December 09, 2016 11:20 AM
>> To: Andrei Pistirica - M16132; richardcochran@gmail.com
>> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; davem@davemloft.net;
>> nicolas.ferre@atmel.com; harinikatakamlinux@gmail.com;
>> harini.katakam@xilinx.com; punnaia@xilinx.com; michals@xilinx.com;
>> anirudh@xilinx.com; boris.brezillon@free-electrons.com;
>> alexandre.belloni@free-electrons.com; tbultel@pixelsurmer.com
>> Subject: RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence
>> GEM.
>>
>> -----Original Message-----
>> > From: Andrei.Pistirica@microchip.com
>> > [mailto:Andrei.Pistirica@microchip.com]
>> > Sent: 8 grudnia 2016 15:42
>> > To: richardcochran@gmail.com
>> > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>> > linux-arm-kernel@lists.infradead.org; davem@davemloft.net;
>> > nicolas.ferre@atmel.com; harinikatakamlinux@gmail.com;
>> > harini.katakam@xilinx.com; punnaia@xilinx.com; michals@xilinx.com;
>> > anirudh@xilinx.com; boris.brezillon@free-electrons.com;
>> > alexandre.belloni@free-electrons.com; tbultel@pixelsurmer.com; Rafal
>> > Ozieblo
>> > Subject: RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
>> Cadence GEM.
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: Richard Cochran [mailto:richardcochran@gmail.com]
>> > > Sent: Wednesday, December 07, 2016 11:04 PM
>> > > To: Andrei Pistirica - M16132
>> > > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
>> > > kernel@lists.infradead.org; davem@davemloft.net;
>> > > nicolas.ferre@atmel.com; harinikatakamlinux@gmail.com;
>> > > harini.katakam@xilinx.com; punnaia@xilinx.com; michals@xilinx.com;
>> > > anirudh@xilinx.com; boris.brezillon@free-electrons.com;
>> > > alexandre.belloni@free-electrons.com; tbultel@pixelsurmer.com;
>> > > rafalo@cadence.com
>> > > Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
>> > > Cadence GEM.
>> > >
>> > > On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
>> > > > > +static s32 gem_ptp_max_adj(unsigned int f_nom) {
>> > > > > + u64 adj;
>> > > > > +
>> > > > > + /* The 48 bits of seconds for the GEM overflows every:
>> > > > > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
>> > > > > + * thus the maximum adjust frequency must not overflow
>> > > > > + CNS
>> > > register:
>> > > > > + *
>> > > > > + * addend = 10^9/nominal_freq
>> > > > > + * adj_max = +/- addend*ppb_max/10^9
>> > > > > + * max_ppb = (2^8-1)*nominal_freq-10^9
>> > > > > + */
>> > > > > + adj = f_nom;
>> > > > > + adj *= 0xffff;
>> > > > > + adj -= 1000000000ULL;
>> > > >
>> > > > What is this computation, and how does it relate to the comment?
>> >
>> > I considered the following simple equation: increment value at nominal
>> frequency (which is 10^9/nominal frequency nsecs) + the maximum drift
>> value (nsecs) <= maximum increment value at nominal frequency (which is
>> 8bit:0xffff).
>> > If maximum drift is written as function of nominal frequency and
>> maximum ppb, then the equation above yields that the maximum ppb is:
>> (2^8 - 1) *nominal_frequency - 10^9. The equation is also simplified by the
>> fact that the drift is written as ppm + 16bit_fractions and the increment
>> value is written as nsec + 16bit_fractions.
>> >
>> > Rafal said that this value is hardcoded: 0x64E6, while Harini said:
>> 250000000.
>>
>> To clarify a little bit. In my reference code this value (0x64E6) was taken
>> from our legacy code. It was used for testing only. I know it should be
>> change to something more accurate. This is the reason why I asked how did
>> you count it (250000000). According to our calculations this value depends
>> on actual set period (incr_ns and incr_sub_ns) and min and max value we
>> can set. The calculation were a little bit intricate, so we decided to leave it
>> as it was.
>>
>> >
>> > I need to dig into this...
>> >
>> > >
>> > > I am not sure what you meant, but it sounds like you are on the wrong
>> track.
>> > > Let me explain...
>> >
>> > Thanks.
>> >
>> > >
>> > > The max_adj has nothing at all to do with the width of the time register.
>> > > Rather, it should reflect the maximum possible change in the tuning
>> word.
>> > >
>> > > For example, with a nominal 8 ns period, the tuning word is 0x80000.
>> > > Looking at running the clock more slowly, the slowest possible word
>> > > is 0x00001, meaning a difference of 0x7FFFF. This implies an
>> > > adjustment of
>> > > 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can
>> > > already have 0x100000, twice as fast, or just under 2 billion ppb.
>> > >
>> > > You should consider the extreme cases to determine the most limited
>> > > (smallest) max_adj value:
>> > >
>> > > Case 1 - high frequency
>> > > ~~~~~~~~~~~~~~~~~~~~~~~
>> > >
>> > > With a nominal 1 ns period, we have the nominal tuning word 0x10000.
>> > > The smallest is 0x1 for a difference of 0xFFFF. This corresponds to
>> > > an adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
>> > >
>> > > Case 2 - low frequency
>> > > ~~~~~~~~~~~~~~~~~~~~~~
>> > >
>> > > With a nominal 255 ns period, the nominal word is 0xFF0000, the
>> > > largest 0xFFFFFF, and the difference is 0xFFFF. This corresponds to
>> > > and adjustment of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
>> > >
>> > > Since 3921508 ppb is a huge adjustment, you can simply use that as a
>> > > safe maximum, ignoring the actual input clock.
>> > >
>> > > Thanks,
>> > > Richard
>> > >
>> > >
>> >
>> > Regards,
>> > Andrei
>> >
>>
>> Best regards,
>> Rafal Ozieblo | Firmware System Engineer,
>> phone nbr.: +48 32 5085469
>> www.cadence.com
>
> Hi Guys,
>
> Based on Richard's input, this is what I want to do for our platforms:
>
> struct macb_ptp_info {
> void (*ptp_init)(struct net_device *ndev);
> void (*ptp_remove)(struct net_device *ndev);
> + s32 (*get_ptp_max_adj)(void);
> unsigned int (*get_tsu_rate)(struct macb *bp);
> int (*get_ts_info)(struct net_device *dev,
> struct ethtool_ts_info *info);
> int (*get_hwtst)(struct net_device *netdev,
> struct ifreq *ifr);
> int (*set_hwtst)(struct net_device *netdev,
> struct ifreq *ifr, int cmd);
> };
>
> +static s32 gem_get_ptp_max_adj(void)
> +{
> + return 3921508;
> +}
>
> static struct macb_ptp_info gem_ptp_info = {
> .ptp_init = gem_ptp_init,
> .ptp_remove = gem_ptp_remove,
> + .get_ptp_max_adj = gem_get_ptp_max_adj,
> .get_tsu_rate = gem_get_tsu_rate,
> .get_ts_info = gem_get_ts_info,
> .get_hwtst = gem_get_hwtst,
> .set_hwtst = gem_set_hwtst,
> };
>
> [...]
> void gem_ptp_init(struct net_device *ndev)
> {
> [...]
> /* nominal frequency and maximum adjustment in ppb */
> bp->tsu_rate = bp->ptp_info->get_tsu_rate(bp);
> + bp->ptp_caps.max_adj = bp->ptp_info->get_ptp_max_adj();
> [...]
> }
>
> Richard, are you agree with this?
>
> Harini, you can fill the callback with the value for your platform. Tell me if you are ok with function's signature.
>
Thanks, this works for me.
Regards,
Harini
^ permalink raw reply
* [PATCH v2] net: macb: Added PCI wrapper for Platform Driver.
From: Bartosz Folta @ 2016-12-12 10:29 UTC (permalink / raw)
To: Nicolas Ferre, David S. Miller, Niklas Cassel, Alexandre Torgue,
Satanand Burla, Raghu Vatsavayi, Simon Horman,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc: Bartosz Folta, Rafal Ozieblo
In-Reply-To: <1481537461-9587-1-git-send-email-bfolta@cadence.com>
There are hardware PCI implementations of Cadence GEM network
controller. This patch will allow to use such hardware with reuse of
existing Platform Driver.
Signed-off-by: Bartosz Folta <bfolta@cadence.com>
---
Changed in v2:
Respin to net-next. Changed patch formatting.
---
drivers/net/ethernet/cadence/Kconfig | 9 ++
drivers/net/ethernet/cadence/Makefile | 1 +
drivers/net/ethernet/cadence/macb.c | 31 +++++--
drivers/net/ethernet/cadence/macb_pci.c | 152 ++++++++++++++++++++++++++++++++
include/linux/platform_data/macb.h | 6 ++
5 files changed, 194 insertions(+), 5 deletions(-)
create mode 100644 drivers/net/ethernet/cadence/macb_pci.c
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f0bcb15..00d833e 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -31,4 +31,13 @@ config MACB
To compile this driver as a module, choose M here: the module
will be called macb.
+config MACB_PCI
+ tristate "Cadence PCI MACB/GEM support"
+ depends on MACB
+ ---help---
+ This is PCI wrapper for MACB driver.
+
+ To compile this driver as a module, choose M here: the module
+ will be called macb_pci.
+
endif # NET_CADENCE
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 91f79b1..4ba7559 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_MACB) += macb.o
+obj-$(CONFIG_MACB_PCI) += macb_pci.o
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 538544a..c0fb80a 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -404,6 +404,8 @@ static int macb_mii_probe(struct net_device *dev)
phy_irq = gpio_to_irq(pdata->phy_irq_pin);
phydev->irq = (phy_irq < 0) ? PHY_POLL : phy_irq;
}
+ } else {
+ phydev->irq = PHY_POLL;
}
/* attach the mac to the phy */
@@ -482,6 +484,9 @@ static int macb_mii_init(struct macb *bp)
goto err_out_unregister_bus;
}
} else {
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ bp->mii_bus->irq[i] = PHY_POLL;
+
if (pdata)
bp->mii_bus->phy_mask = pdata->phy_mask;
@@ -2523,16 +2528,24 @@ static int macb_clk_init(struct platform_device *pdev, struct clk **pclk,
struct clk **hclk, struct clk **tx_clk,
struct clk **rx_clk)
{
+ struct macb_platform_data *pdata;
int err;
- *pclk = devm_clk_get(&pdev->dev, "pclk");
+ pdata = dev_get_platdata(&pdev->dev);
+ if (pdata) {
+ *pclk = pdata->pclk;
+ *hclk = pdata->hclk;
+ } else {
+ *pclk = devm_clk_get(&pdev->dev, "pclk");
+ *hclk = devm_clk_get(&pdev->dev, "hclk");
+ }
+
if (IS_ERR(*pclk)) {
err = PTR_ERR(*pclk);
dev_err(&pdev->dev, "failed to get macb_clk (%u)\n", err);
return err;
}
- *hclk = devm_clk_get(&pdev->dev, "hclk");
if (IS_ERR(*hclk)) {
err = PTR_ERR(*hclk);
dev_err(&pdev->dev, "failed to get hclk (%u)\n", err);
@@ -3107,15 +3120,23 @@ static int at91ether_init(struct platform_device *pdev)
MODULE_DEVICE_TABLE(of, macb_dt_ids);
#endif /* CONFIG_OF */
+static const struct macb_config default_gem_config = {
+ .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO,
+ .dma_burst_length = 16,
+ .clk_init = macb_clk_init,
+ .init = macb_init,
+ .jumbo_max_len = 10240,
+};
+
static int macb_probe(struct platform_device *pdev)
{
+ const struct macb_config *macb_config = &default_gem_config;
int (*clk_init)(struct platform_device *, struct clk **,
struct clk **, struct clk **, struct clk **)
- = macb_clk_init;
- int (*init)(struct platform_device *) = macb_init;
+ = macb_config->clk_init;
+ int (*init)(struct platform_device *) = macb_config->init;
struct device_node *np = pdev->dev.of_node;
struct device_node *phy_node;
- const struct macb_config *macb_config = NULL;
struct clk *pclk, *hclk = NULL, *tx_clk = NULL, *rx_clk = NULL;
unsigned int queue_mask, num_queues;
struct macb_platform_data *pdata;
diff --git a/drivers/net/ethernet/cadence/macb_pci.c b/drivers/net/ethernet/cadence/macb_pci.c
new file mode 100644
index 0000000..b440960
--- /dev/null
+++ b/drivers/net/ethernet/cadence/macb_pci.c
@@ -0,0 +1,152 @@
+/**
+ * macb_pci.c - Cadence GEM PCI wrapper.
+ *
+ * Copyright (C) 2016 Cadence Design Systems - http://www.cadence.com
+ *
+ * Authors: Rafal Ozieblo <rafalo@cadence.com>
+ * Bartosz Folta <bfolta@cadence.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/etherdevice.h>
+#include <linux/pci.h>
+#include <linux/platform_data/macb.h>
+#include <linux/platform_device.h>
+#include "macb.h"
+
+#define PCI_DRIVER_NAME "macb_pci"
+#define PLAT_DRIVER_NAME "macb"
+
+#define CDNS_VENDOR_ID 0x17cd
+#define CDNS_DEVICE_ID 0xe007
+
+#define GEM_PCLK_RATE 50000000
+#define GEM_HCLK_RATE 50000000
+
+static int macb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ int err;
+ struct platform_device *plat_dev;
+ struct platform_device_info plat_info;
+ struct macb_platform_data plat_data;
+ struct resource res[2];
+
+ /* sanity check */
+ if (!id)
+ return -EINVAL;
+
+ /* enable pci device */
+ err = pci_enable_device(pdev);
+ if (err < 0) {
+ dev_err(&pdev->dev, "Enabling PCI device has failed: 0x%04X",
+ err);
+ return -EACCES;
+ }
+
+ pci_set_master(pdev);
+
+ /* set up resources */
+ memset(res, 0x00, sizeof(struct resource) * ARRAY_SIZE(res));
+ res[0].start = pdev->resource[0].start;
+ res[0].end = pdev->resource[0].end;
+ res[0].name = PCI_DRIVER_NAME;
+ res[0].flags = IORESOURCE_MEM;
+ res[1].start = pdev->irq;
+ res[1].name = PCI_DRIVER_NAME;
+ res[1].flags = IORESOURCE_IRQ;
+
+ dev_info(&pdev->dev, "EMAC physical base addr = 0x%p\n",
+ (void *)(uintptr_t)pci_resource_start(pdev, 0));
+
+ /* set up macb platform data */
+ memset(&plat_data, 0, sizeof(plat_data));
+
+ /* initialize clocks */
+ plat_data.pclk = clk_register_fixed_rate(&pdev->dev, "pclk", NULL, 0,
+ GEM_PCLK_RATE);
+ if (IS_ERR(plat_data.pclk)) {
+ err = PTR_ERR(plat_data.pclk);
+ goto err_pclk_register;
+ }
+
+ plat_data.hclk = clk_register_fixed_rate(&pdev->dev, "hclk", NULL, 0,
+ GEM_HCLK_RATE);
+ if (IS_ERR(plat_data.hclk)) {
+ err = PTR_ERR(plat_data.hclk);
+ goto err_hclk_register;
+ }
+
+ /* set up platform device info */
+ memset(&plat_info, 0, sizeof(plat_info));
+ plat_info.parent = &pdev->dev;
+ plat_info.fwnode = pdev->dev.fwnode;
+ plat_info.name = PLAT_DRIVER_NAME;
+ plat_info.id = pdev->devfn;
+ plat_info.res = res;
+ plat_info.num_res = ARRAY_SIZE(res);
+ plat_info.data = &plat_data;
+ plat_info.size_data = sizeof(plat_data);
+ plat_info.dma_mask = DMA_BIT_MASK(32);
+
+ /* register platform device */
+ plat_dev = platform_device_register_full(&plat_info);
+ if (IS_ERR(plat_dev)) {
+ err = PTR_ERR(plat_dev);
+ goto err_plat_dev_register;
+ }
+
+ pci_set_drvdata(pdev, plat_dev);
+
+ return 0;
+
+err_plat_dev_register:
+ clk_unregister(plat_data.hclk);
+
+err_hclk_register:
+ clk_unregister(plat_data.pclk);
+
+err_pclk_register:
+ pci_disable_device(pdev);
+ return err;
+}
+
+void macb_remove(struct pci_dev *pdev)
+{
+ struct platform_device *plat_dev = pci_get_drvdata(pdev);
+ struct macb_platform_data *plat_data = dev_get_platdata(&plat_dev->dev);
+
+ platform_device_unregister(plat_dev);
+ pci_disable_device(pdev);
+ clk_unregister(plat_data->pclk);
+ clk_unregister(plat_data->hclk);
+}
+
+static struct pci_device_id dev_id_table[] = {
+ { PCI_DEVICE(CDNS_VENDOR_ID, CDNS_DEVICE_ID), },
+ { 0, }
+};
+
+static struct pci_driver macb_pci_driver = {
+ .name = PCI_DRIVER_NAME,
+ .id_table = dev_id_table,
+ .probe = macb_probe,
+ .remove = macb_remove,
+};
+
+module_pci_driver(macb_pci_driver);
+MODULE_DEVICE_TABLE(pci, dev_id_table);
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Cadence NIC PCI wrapper");
diff --git a/include/linux/platform_data/macb.h b/include/linux/platform_data/macb.h
index 21b15f6..7815d50 100644
--- a/include/linux/platform_data/macb.h
+++ b/include/linux/platform_data/macb.h
@@ -8,6 +8,8 @@
#ifndef __MACB_PDATA_H__
#define __MACB_PDATA_H__
+#include <linux/clk.h>
+
/**
* struct macb_platform_data - platform data for MACB Ethernet
* @phy_mask: phy mask passed when register the MDIO bus
@@ -15,12 +17,16 @@
* @phy_irq_pin: PHY IRQ
* @is_rmii: using RMII interface?
* @rev_eth_addr: reverse Ethernet address byte order
+ * @pclk: platform clock
+ * @hclk: AHB clock
*/
struct macb_platform_data {
u32 phy_mask;
int phy_irq_pin;
u8 is_rmii;
u8 rev_eth_addr;
+ struct clk *pclk;
+ struct clk *hclk;
};
#endif /* __MACB_PDATA_H__ */
--
1.9.1
^ permalink raw reply related
* Re: 4.9.0-rc8: tg3 dead after resume
From: Siva Reddy Kallam @ 2016-12-12 10:23 UTC (permalink / raw)
To: Billy Shuman; +Cc: Michael Chan, Netdev
On Fri, Dec 9, 2016 at 7:59 PM, Billy Shuman <wshuman3@gmail.com> wrote:
> On Thu, Dec 8, 2016 at 4:03 AM, Siva Reddy Kallam
> <siva.kallam@broadcom.com> wrote:
>> On Thu, Dec 8, 2016 at 12:14 AM, Billy Shuman <wshuman3@gmail.com> wrote:
>>> On Wed, Dec 7, 2016 at 12:37 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>>>> On Wed, Dec 7, 2016 at 7:20 AM, Billy Shuman <wshuman3@gmail.com> wrote:
>>>>> After resume on 4.9.0-rc8 tg3 is dead.
>>>>>
>>>>> In logs I see:
>>>>> kernel: tg3 0000:44:00.0: phy probe failed, err -19
>>>>> kernel: tg3 0000:44:00.0: Problem fetching invariants of chip, aborting
>>>>
>>>> -19 is -ENODEV which means tg3 cannot read the PHY ID.
>>>>
>>>> If it's a true suspend/resume operation, the driver does not have to
>>>> go through probe during resume. Please explain how you do
>>>> suspend/resume.
>>>>
>>>
>>> Sorry my previous message was accidentally sent to early.
>>>
>>> I used systemd (systemctl suspend) to suspend.
>>>
>> We need more information to proceed further.
>> Without suspend, Are you able to use the tg3 port?
>
> Yes the port works fine without suspend.
OK
>
>> Which Broadcom card are you having in laptop?
>
> The nic is a NetXtreme BCM57762 Gigabit Ethernet PCIe in a thunderbolt3 dock.
>
OK
>> Please provide complete tg3 specific logs in dmesg.
>>
>
> [ 32.084010] tg3.c:v3.137 (May 11, 2014)
> [ 32.124695] tg3 0000:44:00.0 eth0: Tigon3 [partno(BCM957762) rev
> 57766001] (PCI Express) MAC address 98:e7:f4:8b:13:19
> [ 32.124698] tg3 0000:44:00.0 eth0: attached PHY is 57765
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [ 32.124699] tg3 0000:44:00.0 eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[0] TSOcap[1]
> [ 32.124700] tg3 0000:44:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit]
> [ 32.219764] tg3 0000:44:00.0 enp68s0: renamed from eth0
> [ 36.219245] tg3 0000:44:00.0 enp68s0: Link is up at 1000 Mbps, full duplex
> [ 36.219250] tg3 0000:44:00.0 enp68s0: Flow control is on for TX and on for RX
> [ 36.219251] tg3 0000:44:00.0 enp68s0: EEE is disabled
>
> after resume
> [ 92.292838] tg3 0000:44:00.0 enp68s0: No firmware running
> [ 93.521744] tg3 0000:44:00.0: tg3_abort_hw timed out,
> TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
> [ 106.704655] tg3 0000:44:00.0 enp68s0: Link is down
> [ 108.370356] tg3 0000:44:00.0: tg3_abort_hw timed out,
> TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
>
> after rmmod, modprobe
> [ 570.933636] tg3 0000:44:00.0: tg3_abort_hw timed out,
> TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
> [ 604.847215] tg3.c:v3.137 (May 11, 2014)
> [ 605.010075] tg3 0000:44:00.0: phy probe failed, err -19
> [ 605.010077] tg3 0000:44:00.0: Problem fetching invariants of chip, aborting
>
>
>
>
We will try to reproduce and update you on this.
>>>> Did this work before? There has been very few changes to tg3 recently.
>>>>
>>>
>>> This is a new laptop for me, but the same behavior is seen on 4.4.36 and 4.8.12.
>>>
>>>>>
>>>>> rmmod and modprobe does not fix the problem only a reboot resolves the issue.
>>>>>
>>>>> Billy
^ 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