* [PATCH 07/10] vsock/virtio: add a missing __le annotation
From: Michael S. Tsirkin @ 2016-12-06 15:40 UTC (permalink / raw)
To: linux-kernel
Cc: kvm, netdev, virtualization, Stefan Hajnoczi, David S. Miller
In-Reply-To: <1481038106-24899-1-git-send-email-mst@redhat.com>
guest cid is read from config space, therefore it's in little endian
format and is treated as such, annotate it accordingly.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
net/vmw_vsock/virtio_transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 936d7ee..90096b9 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -336,7 +336,7 @@ static void virtio_vsock_reset_sock(struct sock *sk)
static void virtio_vsock_update_guest_cid(struct virtio_vsock *vsock)
{
struct virtio_device *vdev = vsock->vdev;
- u64 guest_cid;
+ __le64 guest_cid;
vdev->config->get(vdev, offsetof(struct virtio_vsock_config, guest_cid),
&guest_cid, sizeof(guest_cid));
--
MST
^ permalink raw reply related
* [PATCH 06/10] vhost: add missing __user annotations
From: Michael S. Tsirkin @ 2016-12-06 15:40 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason Wang, kvm, virtualization, netdev
In-Reply-To: <1481038106-24899-1-git-send-email-mst@redhat.com>
Several vhost functions were missing __user annotations
on pointers, causing sparse warnings. Fix this up.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/vhost/vhost.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 7331ef3..ba7db68 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -719,7 +719,7 @@ static int memory_access_ok(struct vhost_dev *d, struct vhost_umem *umem,
static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
struct iovec iov[], int iov_size, int access);
-static int vhost_copy_to_user(struct vhost_virtqueue *vq, void *to,
+static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
const void *from, unsigned size)
{
int ret;
@@ -749,7 +749,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void *to,
}
static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
- void *from, unsigned size)
+ void __user *from, unsigned size)
{
int ret;
@@ -783,7 +783,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
}
static void __user *__vhost_get_user(struct vhost_virtqueue *vq,
- void *addr, unsigned size)
+ void __user *addr, unsigned size)
{
int ret;
@@ -934,8 +934,8 @@ static int umem_access_ok(u64 uaddr, u64 size, int access)
return 0;
}
-int vhost_process_iotlb_msg(struct vhost_dev *dev,
- struct vhost_iotlb_msg *msg)
+static int vhost_process_iotlb_msg(struct vhost_dev *dev,
+ struct vhost_iotlb_msg *msg)
{
int ret = 0;
--
MST
^ permalink raw reply related
* [PATCH 08/10] vsock/virtio: mark an internal function static
From: Michael S. Tsirkin @ 2016-12-06 15:41 UTC (permalink / raw)
To: linux-kernel
Cc: Jason Wang, Stefan Hajnoczi, David S. Miller, kvm, virtualization,
netdev
In-Reply-To: <1481038106-24899-1-git-send-email-mst@redhat.com>
virtio_transport_alloc_pkt is only used locally, make it static.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
net/vmw_vsock/virtio_transport_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index a53b3a1..6120384 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -32,7 +32,7 @@ static const struct virtio_transport *virtio_transport_get_ops(void)
return container_of(t, struct virtio_transport, transport);
}
-struct virtio_vsock_pkt *
+static struct virtio_vsock_pkt *
virtio_transport_alloc_pkt(struct virtio_vsock_pkt_info *info,
size_t len,
u32 src_cid,
--
MST
^ permalink raw reply related
* [PATCH 09/10] vsock/virtio: fix src/dst cid format
From: Michael S. Tsirkin @ 2016-12-06 15:41 UTC (permalink / raw)
To: linux-kernel
Cc: Jason Wang, stable, Stefan Hajnoczi, David S. Miller, kvm,
virtualization, netdev
In-Reply-To: <1481038106-24899-1-git-send-email-mst@redhat.com>
These fields are 64 bit, using le32_to_cpu and friends
on these will not do the right thing.
Fix this up.
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
net/vmw_vsock/virtio_transport_common.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 6120384..22e99c4 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -606,9 +606,9 @@ static int virtio_transport_reset_no_sock(struct virtio_vsock_pkt *pkt)
return 0;
pkt = virtio_transport_alloc_pkt(&info, 0,
- le32_to_cpu(pkt->hdr.dst_cid),
+ le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port),
- le32_to_cpu(pkt->hdr.src_cid),
+ le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
if (!pkt)
return -ENOMEM;
@@ -823,7 +823,7 @@ virtio_transport_send_response(struct vsock_sock *vsk,
struct virtio_vsock_pkt_info info = {
.op = VIRTIO_VSOCK_OP_RESPONSE,
.type = VIRTIO_VSOCK_TYPE_STREAM,
- .remote_cid = le32_to_cpu(pkt->hdr.src_cid),
+ .remote_cid = le64_to_cpu(pkt->hdr.src_cid),
.remote_port = le32_to_cpu(pkt->hdr.src_port),
.reply = true,
};
@@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock *sk, struct virtio_vsock_pkt *pkt)
child->sk_state = SS_CONNECTED;
vchild = vsock_sk(child);
- vsock_addr_init(&vchild->local_addr, le32_to_cpu(pkt->hdr.dst_cid),
+ vsock_addr_init(&vchild->local_addr, le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port));
- vsock_addr_init(&vchild->remote_addr, le32_to_cpu(pkt->hdr.src_cid),
+ vsock_addr_init(&vchild->remote_addr, le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
vsock_insert_connected(vchild);
@@ -904,9 +904,9 @@ void virtio_transport_recv_pkt(struct virtio_vsock_pkt *pkt)
struct sock *sk;
bool space_available;
- vsock_addr_init(&src, le32_to_cpu(pkt->hdr.src_cid),
+ vsock_addr_init(&src, le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
- vsock_addr_init(&dst, le32_to_cpu(pkt->hdr.dst_cid),
+ vsock_addr_init(&dst, le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port));
trace_virtio_transport_recv_pkt(src.svm_cid, src.svm_port,
--
MST
^ permalink raw reply related
* [PATCH 10/10] virtio: enable endian checks for sparse builds
From: Michael S. Tsirkin @ 2016-12-06 15:41 UTC (permalink / raw)
To: linux-kernel
Cc: kvm, Neil Armstrong, Jason Wang, linux-remoteproc, dri-devel,
virtualization, Gerd Hoffmann, linux-s390, James E.J. Bottomley,
Herbert Xu, linux-scsi, Christian Borntraeger, v9fs-developer,
Asias He, Ohad Ben-Cohen, Arnd Bergmann, linux-kbuild, Jens Axboe,
Michal Marek, Stefan Hajnoczi, Matt Mackall, Cornelia Huck,
Greg Kroah-Hartman, linux-crypto, netdev, "David S
In-Reply-To: <1481038106-24899-1-git-send-email-mst@redhat.com>
__CHECK_ENDIAN__ isn't on by default presumably because
it triggers too many sparse warnings for correct code.
But virtio is now clean of these warnings, and
we want to keep it this way - enable this for
sparse builds.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
It seems that there should be a better way to do it,
but this works too.
drivers/block/Makefile | 1 +
drivers/char/Makefile | 1 +
drivers/char/hw_random/Makefile | 2 ++
drivers/gpu/drm/virtio/Makefile | 1 +
drivers/net/Makefile | 3 +++
drivers/net/caif/Makefile | 1 +
drivers/rpmsg/Makefile | 1 +
drivers/s390/virtio/Makefile | 2 ++
drivers/scsi/Makefile | 1 +
drivers/vhost/Makefile | 1 +
drivers/virtio/Makefile | 3 +++
net/9p/Makefile | 1 +
net/packet/Makefile | 1 +
net/vmw_vsock/Makefile | 2 ++
14 files changed, 21 insertions(+)
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 1e9661e..597481c 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_BLK_DEV_OSD) += osdblk.o
obj-$(CONFIG_BLK_DEV_UMEM) += umem.o
obj-$(CONFIG_BLK_DEV_NBD) += nbd.o
obj-$(CONFIG_BLK_DEV_CRYPTOLOOP) += cryptoloop.o
+CFLAGS_virtio_blk.o += -D__CHECK_ENDIAN__
obj-$(CONFIG_VIRTIO_BLK) += virtio_blk.o
obj-$(CONFIG_BLK_DEV_SX8) += sx8.o
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 6e6c244..a99467d 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -6,6 +6,7 @@ obj-y += mem.o random.o
obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o
obj-y += misc.o
obj-$(CONFIG_ATARI_DSP56K) += dsp56k.o
+CFLAGS_virtio_console.o += -D__CHECK_ENDIAN__
obj-$(CONFIG_VIRTIO_CONSOLE) += virtio_console.o
obj-$(CONFIG_RAW_DRIVER) += raw.o
obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 5f52b1e..a2b0931 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -17,6 +17,8 @@ obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
+CFLAGS_virtio_transport.o += -D__CHECK_ENDIAN__
+CFLAGS_virtio-rng.o += -D__CHECK_ENDIAN__
obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index 3fb8eac..1162366 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -3,6 +3,7 @@
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
ccflags-y := -Iinclude/drm
+ccflags-y += -D__CHECK_ENDIAN__
virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 7336cbd..3f587de 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_EQUALIZER) += eql.o
obj-$(CONFIG_IFB) += ifb.o
obj-$(CONFIG_MACSEC) += macsec.o
obj-$(CONFIG_MACVLAN) += macvlan.o
+CFLAGS_macvtap.o += -D__CHECK_ENDIAN__
obj-$(CONFIG_MACVTAP) += macvtap.o
obj-$(CONFIG_MII) += mii.o
obj-$(CONFIG_MDIO) += mdio.o
@@ -20,8 +21,10 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
obj-$(CONFIG_PHYLIB) += phy/
obj-$(CONFIG_RIONET) += rionet.o
obj-$(CONFIG_NET_TEAM) += team/
+CFLAGS_tun.o += -D__CHECK_ENDIAN__
obj-$(CONFIG_TUN) += tun.o
obj-$(CONFIG_VETH) += veth.o
+CFLAGS_virtio_net.o += -D__CHECK_ENDIAN__
obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
obj-$(CONFIG_VXLAN) += vxlan.o
obj-$(CONFIG_GENEVE) += geneve.o
diff --git a/drivers/net/caif/Makefile b/drivers/net/caif/Makefile
index 9bbd453..d1a922c 100644
--- a/drivers/net/caif/Makefile
+++ b/drivers/net/caif/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_CAIF_HSI) += caif_hsi.o
# Virtio interface
obj-$(CONFIG_CAIF_VIRTIO) += caif_virtio.o
+CFLAGS_caif_virtio.o += -D__CHECK_ENDIAN__
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index ae9c913..23c8b66 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_RPMSG) += rpmsg_core.o
obj-$(CONFIG_RPMSG_QCOM_SMD) += qcom_smd.o
obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
+CFLAGS_virtio_rpmsg_bus.o += -D__CHECK_ENDIAN__
diff --git a/drivers/s390/virtio/Makefile b/drivers/s390/virtio/Makefile
index df40692..270ada5 100644
--- a/drivers/s390/virtio/Makefile
+++ b/drivers/s390/virtio/Makefile
@@ -6,6 +6,8 @@
# it under the terms of the GNU General Public License (version 2 only)
# as published by the Free Software Foundation.
+CFLAGS_virtio_ccw.o += -D__CHECK_ENDIAN__
+CFLAGS_kvm_virtio.o += -D__CHECK_ENDIAN__
s390-virtio-objs := virtio_ccw.o
ifdef CONFIG_S390_GUEST_OLD_TRANSPORT
s390-virtio-objs += kvm_virtio.o
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 38d938d..9f70d46 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -135,6 +135,7 @@ obj-$(CONFIG_SCSI_BNX2_ISCSI) += libiscsi.o bnx2i/
obj-$(CONFIG_BE2ISCSI) += libiscsi.o be2iscsi/
obj-$(CONFIG_SCSI_ESAS2R) += esas2r/
obj-$(CONFIG_SCSI_PMCRAID) += pmcraid.o
+CFLAGS_virtio_scsi.o += -D__CHECK_ENDIAN__
obj-$(CONFIG_SCSI_VIRTIO) += virtio_scsi.o
obj-$(CONFIG_VMWARE_PVSCSI) += vmw_pvscsi.o
obj-$(CONFIG_XEN_SCSI_FRONTEND) += xen-scsifront.o
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 6b012b9..619e2cd 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -1,3 +1,4 @@
+ccflags-y := -D__CHECK_ENDIAN__
obj-$(CONFIG_VHOST_NET) += vhost_net.o
vhost_net-y := net.o
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 41e30e3..d331f19 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -1,3 +1,6 @@
+#virtio must be kept clean wrt endian tags,
+#otherwise we'll get to maintain broken host/guest ABIs
+ccflags-y := -D__CHECK_ENDIAN__
obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
diff --git a/net/9p/Makefile b/net/9p/Makefile
index a0874cc..acf1225 100644
--- a/net/9p/Makefile
+++ b/net/9p/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_NET_9P_RDMA) += 9pnet_rdma.o
trans_fd.o \
trans_common.o \
+CFLAGS_trans_virtio.o += -D__CHECK_ENDIAN__
9pnet_virtio-objs := \
trans_virtio.o \
diff --git a/net/packet/Makefile b/net/packet/Makefile
index 9df6134..a13bcb3 100644
--- a/net/packet/Makefile
+++ b/net/packet/Makefile
@@ -2,6 +2,7 @@
# Makefile for the packet AF.
#
+ccflags-y := -D__CHECK_ENDIAN__
obj-$(CONFIG_PACKET) += af_packet.o
obj-$(CONFIG_PACKET_DIAG) += af_packet_diag.o
af_packet_diag-y += diag.o
diff --git a/net/vmw_vsock/Makefile b/net/vmw_vsock/Makefile
index bc27c70..a61eccb 100644
--- a/net/vmw_vsock/Makefile
+++ b/net/vmw_vsock/Makefile
@@ -8,6 +8,8 @@ vsock-y += af_vsock.o vsock_addr.o
vmw_vsock_vmci_transport-y += vmci_transport.o vmci_transport_notify.o \
vmci_transport_notify_qstate.o
+CFLAGS_virtio_transport.o += -D__CHECK_ENDIAN__
+CFLAGS_virtio_transport_common.o += -D__CHECK_ENDIAN__
vmw_vsock_virtio_transport-y += virtio_transport.o
vmw_vsock_virtio_transport_common-y += virtio_transport_common.o
--
MST
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* ATENCIÓN;
From: Sistemas administrador @ 2016-12-06 15:01 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2016
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: [PATCH] net/udp: do not touch skb->peeked unless really needed
From: David Miller @ 2016-12-06 15:42 UTC (permalink / raw)
To: eric.dumazet; +Cc: pabeni, netdev, willemb
In-Reply-To: <1480960639.18162.556.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 05 Dec 2016 09:57:19 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In UDP recvmsg() path we currently access 3 cache lines from an skb
> while holding receive queue lock, plus another one if packet is
> dequeued, since we need to change skb->next->prev
>
> 1st cache line (contains ->next/prev pointers, offsets 0x00 and 0x08)
> 2nd cache line (skb->len & skb->peeked, offsets 0x80 and 0x8e)
> 3rd cache line (skb->truesize/users, offsets 0xe0 and 0xe4)
>
> skb->peeked is only needed to make sure 0-length packets are properly
> handled while MSG_PEEK is operated.
>
> I had first the intent to remove skb->peeked but the "MSG_PEEK at
> non-zero offset" support added by Sam Kumar makes this not possible.
>
> This patch avoids one cache line miss during the locked section, when
> skb->len and skb->peeked do not have to be read.
>
> It also avoids the skb_set_peeked() cost for non empty UDP datagrams.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* RE: [PATCH net-next] phy: add phy fixup unregister functions
From: Woojung.Huh @ 2016-12-06 15:44 UTC (permalink / raw)
To: davem; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <20161206.100104.1134856835372946560.davem@davemloft.net>
> Please submit this along with whatever will be the first user(s) of these
> new interfaces.
Thanks David.
This usage of this will be part of another patch (https://patchwork.ozlabs.org/patch/700141/)
Would it be ok to include other patch in new version of patch?
Thanks.
Woojung
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself
From: Rob Herring @ 2016-12-06 15:52 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Liam Girdwood,
Mark Brown, Nicolas Ferre, Arnd Bergmann, Greg Kroah-Hartman,
Jaroslav Kysela, Takashi Iwai, devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480593549-6464-3-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On Thu, Dec 01, 2016 at 12:59:09PM +0100, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
> ---
> .../bindings/sound/axentia,tse850-pcm5142.txt | 5 ++---
> sound/soc/atmel/tse850-pcm5142.c | 23 +++-------------------
> 2 files changed, 5 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
> index 5b9b38f578bb..fd12ecb35b5c 100644
> --- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
> +++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
> @@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex
>
> Required properties:
> - compatible: "axentia,tse850-pcm5142"
> - - axentia,ssc-controller: The phandle of the atmel SSC controller used as
> - cpu dai.
> + - axentia,cpu-dai: The phandle of the cpu dai.
You are breaking backwards compatibility with old DTBs. You either need
to not do that or explain in the commit why that is okay.
Rob
--
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
* Re: [PATCH net-next] phy: add phy fixup unregister functions
From: David Miller @ 2016-12-06 15:56 UTC (permalink / raw)
To: Woojung.Huh; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D4097823A@CHN-SV-EXMX02.mchp-main.com>
From: <Woojung.Huh@microchip.com>
Date: Tue, 6 Dec 2016 15:44:39 +0000
>> Please submit this along with whatever will be the first user(s) of these
>> new interfaces.
> Thanks David.
>
> This usage of this will be part of another patch (https://patchwork.ozlabs.org/patch/700141/)
> Would it be ok to include other patch in new version of patch?
You must post them together as a series, yes.
^ permalink raw reply
* RE: [PATCH net-next] phy: add phy fixup unregister functions
From: Woojung.Huh @ 2016-12-06 15:57 UTC (permalink / raw)
To: davem; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <20161206.105645.1977694670278384013.davem@davemloft.net>
Thanks. Will do it.
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, December 06, 2016 10:57 AM
> To: Woojung Huh - C21699
> Cc: f.fainelli@gmail.com; andrew@lunn.ch; netdev@vger.kernel.org
> Subject: Re: [PATCH net-next] phy: add phy fixup unregister functions
>
> From: <Woojung.Huh@microchip.com>
> Date: Tue, 6 Dec 2016 15:44:39 +0000
>
> >> Please submit this along with whatever will be the first user(s) of these
> >> new interfaces.
> > Thanks David.
> >
> > This usage of this will be part of another patch
> (https://patchwork.ozlabs.org/patch/700141/)
> > Would it be ok to include other patch in new version of patch?
>
> You must post them together as a series, yes.
^ permalink raw reply
* Re: [PATCH resend 0/8] irda: w83977af_ir: Neatening
From: David Miller @ 2016-12-06 15:59 UTC (permalink / raw)
To: joe; +Cc: netdev, arnd, sergei.shtylyov, samuel, linux-kernel
In-Reply-To: <cover.1480963809.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 5 Dec 2016 11:00:40 -0800
> On top of Arnd's overly long udelay patch because I noticed a
> misindented block.
Joe, this doesn't apply cleanly to net-next, please respin.
Thank you.
^ permalink raw reply
* Re: [PATCH net v4] tcp: warn on bogus MSS and try to amend it
From: David Miller @ 2016-12-06 16:01 UTC (permalink / raw)
To: marcelo.leitner
Cc: netdev, jmaxwell37, alexandre.sidorenko, kuznet, jmorris,
yoshfuji, kaber, tlfalcon, brking, eric.dumazet
In-Reply-To: <2056cf96b896aa473ff017b9f223904a14bfed86.1480969929.git.marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Mon, 5 Dec 2016 18:37:13 -0200
> There have been some reports lately about TCP connection stalls caused
> by NIC drivers that aren't setting gso_size on aggregated packets on rx
> path. This causes TCP to assume that the MSS is actually the size of the
> aggregated packet, which is invalid.
>
> Although the proper fix is to be done at each driver, it's often hard
> and cumbersome for one to debug, come to such root cause and report/fix
> it.
>
> This patch amends this situation in two ways. First, it adds a warning
> on when this situation occurs, so it gives a hint to those trying to
> debug this. It also limit the maximum probed MSS to the adverised MSS,
> as it should never be any higher than that.
>
> The result is that the connection may not have the best performance ever
> but it shouldn't stall, and the admin will have a hint on what to look
> for.
>
> Tested with virtio by forcing gso_size to 0.
>
> v2: updated msg per David's suggestion
> v3: use skb_iif to find the interface and also log its name, per Eric
> Dumazet's suggestion. As the skb may be backlogged and the interface
> gone by then, we need to check if the number still has a meaning.
> v4: use helper tcp_gro_dev_warn() and avoid pr_warn_once inside __once, per
> David's suggestion
>
> Cc: Jonathan Maxwell <jmaxwell37@gmail.com>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Applied, thanks Marcelo.
^ permalink raw reply
* Re: Gigabit ethernet driver for Alacritechs SLIC devices (v4)
From: David Miller @ 2016-12-06 16:30 UTC (permalink / raw)
To: LinoSanfilippo
Cc: devel, andrew, f.fainelli, roszenrami, gregkh, linux-kernel,
liodot, netdev
In-Reply-To: <1480975637-18245-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Mon, 5 Dec 2016 23:07:15 +0100
> this is the forth version of the slicoss gigabit ethernet driver (which is a
> rework of the driver from Alacritech which can currently be found under
> drivers/staging/slicoss). The driver is supposed to support Mojave, Oasis and
> Kalahari cards, for both copper and fiber.
>
> If this code is accepted the staging version can be removed.
>
> The driver has been tested on a SEN2104ET adapter (4 Port PCIe copper).
I've applied this series, nice work.
But realize that if you use SLICOSS as the Kconfig symbol to select
this driver, then while the staging driver is still in the tree it
will enable both drivers which both want to attach to the same exact
device IDs.
^ permalink raw reply
* Re: [PATCH next] Revert "dctcp: update cwnd on congestion event"
From: David Miller @ 2016-12-06 16:34 UTC (permalink / raw)
To: fw; +Cc: netdev, ncardwell
In-Reply-To: <1480980180-23349-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 6 Dec 2016 00:23:00 +0100
> Neal Cardwell says:
> If I am reading the code correctly, then I would have two concerns:
> 1) Has that been tested? That seems like an extremely dramatic
> decrease in cwnd. For example, if the cwnd is 80, and there are 40
> ACKs, and half the ACKs are ECE marked, then my back-of-the-envelope
> calculations seem to suggest that after just 11 ACKs the cwnd would be
> down to a minimal value of 2 [..]
> 2) That seems to contradict another passage in the draft [..] where it
> sazs:
> Just as specified in [RFC3168], DCTCP does not react to congestion
> indications more than once for every window of data.
>
> Neal is right. Fortunately we don't have to complicate this by testing
> vs. current rtt estimate, we can just revert the patch.
>
> Normal stack already handles this for us: receiving ACKs with ECE
> set causes a call to tcp_enter_cwr(), from there on the ssthresh gets
> adjusted and prr will take care of cwnd adjustment.
>
> Fixes: 4780566784b396 ("dctcp: update cwnd on congestion event")
> Cc: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied.
^ permalink raw reply
* Re: [PATCH] drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" links
From: David Miller @ 2016-12-06 16:36 UTC (permalink / raw)
To: alex.g
Cc: mugunthanvnm, grygorii.strashko, linux-omap, netdev, linux-kernel,
gokhan
In-Reply-To: <1480988033-16535-1-git-send-email-alex.g@adaptrum.com>
From: Alexandru Gagniuc <alex.g@adaptrum.com>
Date: Mon, 5 Dec 2016 17:33:53 -0800
> Support for setting the RGMII_IDMODE bit was added in commit:
> "drivers: net: cpsw-phy-sel: add support to configure rgmii internal delay"
> However, that commit did not add the symmetrical clearing of the bit
> by way of setting it in "mask". Add it here.
>
> Note that the documentation marks clearing this bit as "reserved",
> however, according to TI, support for delaying the clock does exist in
> the MAC, although it is not officially supported.
> We tested this on a board with an RGMII to RGMII link that will not
> work unless this bit is cleared.
>
> Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
Commits must be referenced by both short-form SHA1-ID as well as
the commit header text.
And since this change is fixing that commit, you should also provide
a proper "Fixes: " tag on the line right before your signoff.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: cpsw: fix early budget split
From: David Miller @ 2016-12-06 16:37 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: mugunthanvnm, grygorii.strashko, linux-omap, netdev, linux-kernel
In-Reply-To: <1480988700-17046-1-git-send-email-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 6 Dec 2016 03:45:00 +0200
> The budget split function requires the phy speed to be known.
> While ndo open a phy speed identification is postponed till the
> moment link is up. Hence, move it to appropriate callback, when link
> is up.
>
> Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Fixes: 8feb0a196507 ("net: ethernet: ti: cpsw: split tx budget according between channels")
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH] virtio-net: Fix DMA-from-the-stack in virtnet_set_mac_address()
From: David Miller @ 2016-12-06 16:39 UTC (permalink / raw)
To: luto; +Cc: netdev, linux-kernel, virtualization, mst, jasowang, labbott
In-Reply-To: <fe889e578d5dffa9ae0834b449a35fcfd1e10694.1480990173.git.luto@kernel.org>
From: Andy Lutomirski <luto@kernel.org>
Date: Mon, 5 Dec 2016 18:10:58 -0800
> With CONFIG_VMAP_STACK=y, virtnet_set_mac_address() can be passed a
> pointer to the stack and it will OOPS. Copy the address to the heap
> to prevent the crash.
>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Laura Abbott <labbott@redhat.com>
> Reported-by: zbyszek@in.waw.pl
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
Applied, thanks.
^ permalink raw reply
* Re: Gigabit ethernet driver for Alacritechs SLIC devices (v4)
From: Greg KH @ 2016-12-06 16:40 UTC (permalink / raw)
To: David Miller
Cc: LinoSanfilippo, charrer, liodot, andrew, roszenrami,
markus.boehme, f.fainelli, devel, linux-kernel, netdev
In-Reply-To: <20161206.113004.1297109434722530511.davem@davemloft.net>
On Tue, Dec 06, 2016 at 11:30:04AM -0500, David Miller wrote:
> From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
> Date: Mon, 5 Dec 2016 23:07:15 +0100
>
> > this is the forth version of the slicoss gigabit ethernet driver (which is a
> > rework of the driver from Alacritech which can currently be found under
> > drivers/staging/slicoss). The driver is supposed to support Mojave, Oasis and
> > Kalahari cards, for both copper and fiber.
> >
> > If this code is accepted the staging version can be removed.
> >
> > The driver has been tested on a SEN2104ET adapter (4 Port PCIe copper).
>
> I've applied this series, nice work.
>
> But realize that if you use SLICOSS as the Kconfig symbol to select
> this driver, then while the staging driver is still in the tree it
> will enable both drivers which both want to attach to the same exact
> device IDs.
If you have taken this in your tree now, I will go delete the staging
driver from the staging tree, so we will not have that issue. Should I
do that now?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net] be2net: Add DEVSEC privilege to SET_HSW_CONFIG command.
From: David Miller @ 2016-12-06 16:41 UTC (permalink / raw)
To: suresh.reddy; +Cc: netdev, venkatkumar.duvvuru
In-Reply-To: <20161206053350.23203-1-suresh.reddy@broadcom.com>
From: Suresh Reddy <suresh.reddy@broadcom.com>
Date: Tue, 6 Dec 2016 00:33:50 -0500
> From: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
>
> OPCODE_COMMON_GET_FN_PRIVILEGES is returning only DEVSEC
> privilege (Unrestricted Administrative Privilege) for Lancer NIC functions.
> So, driver is failing SET_HSW_CONFIG command, as DEVSEC privilege was not
> set in the privilege bitmap. This patch fixes the problem by setting DEVSEC
> privilege in SET_HSW_CONFIG’s privilege bitmap.
>
> Signed-off-by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
> Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
Applied.
^ permalink raw reply
* Re: [patch net v4] net: fec: fix compile with CONFIG_M5272
From: David Miller @ 2016-12-06 16:41 UTC (permalink / raw)
To: nikita.yoush
Cc: fugang.duan, troy.kisky, andrew, eric, tremyfr, johannes, netdev,
cphealy, fabio.estevam, linux-kernel
In-Reply-To: <1481005613-5147-1-git-send-email-nikita.yoush@cogentembedded.com>
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date: Tue, 6 Dec 2016 09:26:53 +0300
> Commit 80cca775cdc4 ("net: fec: cache statistics while device is down")
> introduced unconditional statistics-related actions.
>
> However, when driver is compiled with CONFIG_M5272, staticsics-related
> definitions do not exist, which results into build errors.
>
> Fix that by adding explicit handling of !defined(CONFIG_M5272) case.
>
> Fixes: 80cca775cdc4 ("net: fec: cache statistics while device is down")
> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH V4 net-next] net: hns: Fix to conditionally convey RX checksum flag to stack
From: David Miller @ 2016-12-06 16:43 UTC (permalink / raw)
To: salil.mehta; +Cc: yisen.zhuang, mehta.salil.lnk, netdev, linux-kernel, linuxarm
In-Reply-To: <20161206110946.734344-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Tue, 6 Dec 2016 11:09:46 +0000
> This patch introduces the RX checksum function to check the
> status of the hardware calculated checksum and its error and
> appropriately convey status to the upper stack in skb->ip_summed
> field.
>
> In hardware, we only support checksum for the following
> protocols:
> 1) IPv4,
> 2) TCP(over IPv4 or IPv6),
> 3) UDP(over IPv4 or IPv6),
> 4) SCTP(over IPv4 or IPv6)
> but we support many L3(IPv4, IPv6, MPLS, PPPoE etc) and
> L4(TCP, UDP, GRE, SCTP, IGMP, ICMP etc.) protocols.
>
> Hardware limitation:
> Our present hardware RX Descriptor lacks L3/L4 checksum
> "Status & Error" bit (which usually can be used to indicate whether
> checksum was calculated by the hardware and if there was any error
> encountered during checksum calculation).
>
> Software workaround:
> We do get info within the RX descriptor about the kind of
> L3/L4 protocol coming in the packet and the error status. These
> errors might not just be checksum errors but could be related to
> version, length of IPv4, UDP, TCP etc.
> Because there is no-way of knowing if it is a L3/L4 error due
> to bad checksum or any other L3/L4 error, we will not (cannot)
> convey hardware checksum status(CHECKSUM_UNNECESSARY) for such
> cases to upper stack and will not maintain the RX L3/L4 checksum
> counters as well.
>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next v3 0/4] net: dsa: mv88e6xxx: rework reset and PPU code
From: David Miller @ 2016-12-06 16:33 UTC (permalink / raw)
To: vivien.didelot
Cc: netdev, linux-kernel, kernel, f.fainelli, andrew, eichest,
richardcochran
In-Reply-To: <20161205223028.20308-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 5 Dec 2016 17:30:24 -0500
> Old Marvell chips (like 88E6060) don't have a PHY Polling Unit (PPU).
>
> Next chips (like 88E6185) have a PPU, which has exclusive access to the
> PHY registers, thus must be disabled before access.
>
> Newer chips (like 88E6352) have an indirect mechanism to access the PHY
> registers whenever, thus loose control over the PPU (always enabled).
>
> Here's a summary:
>
> Model | PPU? | Has PPU ctrl? | PPU state readable? | PHY access
> ----- | ---- | -------------- | ------------------- | ----------
> 6060 | no | no | no | direct
> 6185 | yes | yes, PPUEn bit | yes, PPUState 2-bit | direct w/ PPU dis.
> 6352 | yes | no | yes, PPUState 1-bit | indirect
> 6390 | yes | no | yes, InitState bit | indirect
>
> Depending on the PPU control, a switch may have to restart the PPU when
> resetting the switch. Once the switch is reset, we must wait for the PPU
> state to be active polling again before accessing the registers.
>
> For that purpose, add new operations to the chips to enable/disable the
> PPU, and execute software reset. With these new ops in place, rework the
> switch reset code and finally get rid of the MV88E6XXX_FLAG_PPU* flags.
Series applied, thanks Vivien.
And thanks for the detailed, informative, header postings like this one.
^ permalink raw reply
* Re: [PATCH net V2 0/6] Mellanox 100G mlx5 fixes 2016-12-04
From: David Miller @ 2016-12-06 16:45 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <1481038368-29677-1-git-send-email-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 6 Dec 2016 17:32:42 +0200
> Some bug fixes for mlx5 core and mlx5e driver.
>
> v1->v2:
> - replace "uint" with "unsigned int"
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v4 09/13] net: ethernet: ti: cpts: rework initialization/deinitialization
From: Grygorii Strashko @ 2016-12-06 16:45 UTC (permalink / raw)
To: Richard Cochran
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Mugunthan V N,
Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Murali Karicheri, Wingman Kwok,
Thomas Gleixner
In-Reply-To: <20161206134037.GA15946-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 12/06/2016 07:40 AM, Richard Cochran wrote:
> On Mon, Dec 05, 2016 at 02:05:21PM -0600, Grygorii Strashko wrote:
>> @@ -372,34 +354,27 @@ void cpts_tx_timestamp(struct cpts *cpts, struct sk_buff *skb)
>> }
>> EXPORT_SYMBOL_GPL(cpts_tx_timestamp);
>>
>> -int cpts_register(struct device *dev, struct cpts *cpts,
>> - u32 mult, u32 shift)
>> +int cpts_register(struct cpts *cpts)
>> {
>> int err, i;
>>
>> - cpts->info = cpts_info;
>> - spin_lock_init(&cpts->lock);
>> -
>> - cpts->cc.read = cpts_systim_read;
>> - cpts->cc.mask = CLOCKSOURCE_MASK(32);
>> - cpts->cc_mult = mult;
>> - cpts->cc.mult = mult;
>> - cpts->cc.shift = shift;
>> -
>> INIT_LIST_HEAD(&cpts->events);
>> INIT_LIST_HEAD(&cpts->pool);
>> for (i = 0; i < CPTS_MAX_EVENTS; i++)
>> list_add(&cpts->pool_data[i].list, &cpts->pool);
>>
>> - cpts_clk_init(dev, cpts);
>> + clk_enable(cpts->refclk);
>> +
>> cpts_write32(cpts, CPTS_EN, control);
>> cpts_write32(cpts, TS_PEND_EN, int_enable);
>>
>> + /* reinitialize cc.mult to original value as it can be modified
>> + * by cpts_ptp_adjfreq().
>> + */
>> + cpts->cc.mult = cpts->cc_mult;
>
> This still isn't quite right. First of all, you shouldn't clobber the
> learned cc.mult value in cpts_register(). Presumably, if PTP had been
> run on this port before, then the learned frequency is approximately
> correct, and it should be left alone.
>
> [ BTW, resetting the timecounter here makes no sense either. Why
> reset the clock just because the interface goes down? ]
>
Huh. This is how it works now (even before my changes) - this is just refactoring!
(really new thing is the only cpts_calc_mult_shift()).
Also, this is how cpts is supported now as part of cpsw (and keystone):
configure cpsw (cpts)
- ifup
cpsw (*soft_reset*, full reconfiguration of cpsw)
(start cpts) - cpts/ptp active
- ifdown
if last netdev - shutdown/poweroff cpsw (cpts)
in other words, cpts/ptp is expected to work once and until at least one cpsw netdev is active.
Also there are additional questions such as:
- is there guarantee that cpsw port will be connected to the same network after ifup?
- should there be possibility to reset cc.mult if it's value will be kept from the previous run?
> Secondly, you have made the initialization order of these fields hard
> to follow. With the whole series applied:
>
> probe()
> cpts_create()
> cpts_of_parse()
> {
> /* Set cc_mult but not cc.mult! */
> set cc_mult
> set cc.shift
> }
> cpts_calc_mult_shift()
> {
> /* Set them both. */
> cpts->cc_mult = mult;
> cpts->cc.mult = mult;
^^ this assignment of cpts->cc.mult not required.
> cpts->cc.shift = shift;
only in case there were not set in DT before
(I have a requirement to support both - DT and cpts_calc_mult_shift and
that introduces a bit of complexity)
Also, I've tried not to add more fields in struct cpts.
> }
> /* later on */
> cpts_register()
> cpts->cc.mult = cpts->cc_mult;
>
> There is no need for such complexity. Simply set cc.mult in
> cpts_create() _once_, immediately after the call to
> cpts_calc_mult_shift().
>
> You can remove the assignment from cpts_calc_mult_shift() and
> cpts_register().
Just to clarify: do you propose to get rid of cpts->cc_mult at all?
static int cpts_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
{
...
if (ppb < 0) {
neg_adj = 1;
ppb = -ppb;
}
mult = cpts->cc_mult;
^^^^^^^^^^^^^^
adj = mult;
adj *= ppb;
diff = div_u64(adj, 1000000000ULL);
...
cpts->cc.mult = neg_adj ? mult - diff : mult + diff;
Honestly, i'd not prefer to change functional behavior of ptp clock as part of
this series.
--
regards,
-grygorii
--
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
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