* Re: [PATCH v2] wimax/i2400m: fix a memory leak bug
From: Perez-Gonzalez, Inaky @ 2019-08-18 22:22 UTC (permalink / raw)
To: David Miller
Cc: wenwen@cs.uga.edu, linux-wimax, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190818.141158.218871786116375619.davem@davemloft.net>
This driver should be orphaned.
While I can’t certainly say nobody is using it, the HW has not been sold for years and it hasn’t been brought to current LK standards.
If your assesment is the code shall not be used, it’s then another argument towards disconnecting it.
> On Aug 18, 2019, at 14:12, David Miller <davem@davemloft.net> wrote:
>
> From: Wenwen Wang <wenwen@cs.uga.edu>
> Date: Thu, 15 Aug 2019 15:29:51 -0500
>
>> In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
>> to hold the original command line options. Then, the options are parsed.
>> However, if an error occurs during the parsing process, 'options_orig' is
>> not deallocated, leading to a memory leak bug. To fix this issue, free
>> 'options_orig' before returning the error.
>>
>> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
>
> Applied, but... looking at the rest of this file I hope nobody is actually
> running this code.
^ permalink raw reply
* Re: [PATCH 1/2] PTP: introduce new versions of IOCTLs
From: Joe Perches @ 2019-08-18 22:07 UTC (permalink / raw)
To: Richard Cochran; +Cc: Felipe Balbi, Christopher S Hall, netdev, linux-kernel
In-Reply-To: <20190818201150.GA1316@localhost>
On Sun, 2019-08-18 at 13:11 -0700, Richard Cochran wrote:
> On Sat, Aug 17, 2019 at 09:17:20AM -0700, Joe Perches wrote:
> > Is there a case where this initialization is
> > unnecessary such that it impacts performance
> > given the use in ptp_ioctl?
>
> None of these ioctls are sensitive WRT performance. They are all
> setup or configuration, or in the case of the OFFSET ioctls, the tiny
> extra delay before the actual measurement will not affect the result.
>
> Thanks,
> Richard
Still, my preference would be to move the struct declarations
into the switch/case blocks where they are used instead of
having a large declaration block at the top of the function.
This minimizes stack use and makes the declarations use {}
Also the original patch deletes 2 case entries for
PTP_PIN_GETFUNC and PTP_PIN_SETFUNC and converts them to
PTP_PIN_GETFUNC2 and PTP_PIN_SETFUNC2 but still uses tests
for the deleted case label entries making part of the case
code block unreachable.
That's at least a defect:
- case PTP_PIN_GETFUNC:
+ case PTP_PIN_GETFUNC2:
and
- case PTP_PIN_SETFUNC:
+ case PTP_PIN_SETFUNC2:
Anyway, leaving aside that nominal defect, which
should probably leave the original case labels in place,
I suggest:
---
drivers/ptp/ptp_chardev.c | 106 +++++++++++++++++++++++++++++++++++++++-------
1 file changed, 91 insertions(+), 15 deletions(-)
diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 18ffe449efdf..a77f12e6326b 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -110,23 +110,17 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
struct ptp_sys_offset_extended *extoff = NULL;
- struct ptp_sys_offset_precise precise_offset;
- struct system_device_crosststamp xtstamp;
- struct ptp_clock_info *ops = ptp->info;
struct ptp_sys_offset *sysoff = NULL;
- struct ptp_system_timestamp sts;
- struct ptp_clock_request req;
- struct ptp_clock_caps caps;
- struct ptp_clock_time *pct;
+ struct ptp_clock_info *ops = ptp->info;
unsigned int i, pin_index;
- struct ptp_pin_desc pd;
- struct timespec64 ts;
int enable, err = 0;
switch (cmd) {
case PTP_CLOCK_GETCAPS:
- memset(&caps, 0, sizeof(caps));
+ case PTP_CLOCK_GETCAPS2: {
+ struct ptp_clock_caps caps = {};
+
caps.max_adj = ptp->info->max_adj;
caps.n_alarm = ptp->info->n_alarm;
caps.n_ext_ts = ptp->info->n_ext_ts;
@@ -137,13 +131,28 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
if (copy_to_user((void __user *)arg, &caps, sizeof(caps)))
err = -EFAULT;
break;
+ }
case PTP_EXTTS_REQUEST:
+ case PTP_EXTTS_REQUEST2: {
+ struct ptp_clock_request req = {};
+
if (copy_from_user(&req.extts, (void __user *)arg,
sizeof(req.extts))) {
err = -EFAULT;
break;
}
+ if (cmd == PTP_EXTTS_REQUEST2 &&
+ (req.extts.flags || req.extts.rsv[0] || req.extts.rsv[1])) {
+ err = -EINVAL;
+ break;
+ }
+ if (cmd == PTP_EXTTS_REQUEST) {
+ req.extts.flags = 0;
+ req.extts.rsv[0] = 0;
+ req.extts.rsv[1] = 0;
+ }
+
if (req.extts.index >= ops->n_ext_ts) {
err = -EINVAL;
break;
@@ -152,13 +161,30 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
enable = req.extts.flags & PTP_ENABLE_FEATURE ? 1 : 0;
err = ops->enable(ops, &req, enable);
break;
+ }
case PTP_PEROUT_REQUEST:
+ case PTP_PEROUT_REQUEST2: {
+ struct ptp_clock_request req = {};
+
if (copy_from_user(&req.perout, (void __user *)arg,
sizeof(req.perout))) {
err = -EFAULT;
break;
}
+ if (cmd == PTP_PEROUT_REQUEST2 &&
+ (req.perout.flags ||
+ req.perout.rsv[0] || req.perout.rsv[1] ||
+ req.perout.rsv[2] || req.perout.rsv[3])) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_PEROUT_REQUEST) {
+ req.perout.flags = 0;
+ req.perout.rsv[0] = 0;
+ req.perout.rsv[1] = 0;
+ req.perout.rsv[2] = 0;
+ req.perout.rsv[3] = 0;
+ }
if (req.perout.index >= ops->n_per_out) {
err = -EINVAL;
break;
@@ -167,16 +193,26 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
enable = req.perout.period.sec || req.perout.period.nsec;
err = ops->enable(ops, &req, enable);
break;
+ }
case PTP_ENABLE_PPS:
+ case PTP_ENABLE_PPS2: {
+ struct ptp_clock_request req = {};
+
if (!capable(CAP_SYS_TIME))
return -EPERM;
req.type = PTP_CLK_REQ_PPS;
enable = arg ? 1 : 0;
err = ops->enable(ops, &req, enable);
break;
+ }
case PTP_SYS_OFFSET_PRECISE:
+ case PTP_SYS_OFFSET_PRECISE2: {
+ struct ptp_sys_offset_precise precise_offset = {};
+ struct system_device_crosststamp xtstamp;
+ struct timespec64 ts;
+
if (!ptp->info->getcrosststamp) {
err = -EOPNOTSUPP;
break;
@@ -185,7 +221,6 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
if (err)
break;
- memset(&precise_offset, 0, sizeof(precise_offset));
ts = ktime_to_timespec64(xtstamp.device);
precise_offset.device.sec = ts.tv_sec;
precise_offset.device.nsec = ts.tv_nsec;
@@ -199,8 +234,13 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
sizeof(precise_offset)))
err = -EFAULT;
break;
+ }
case PTP_SYS_OFFSET_EXTENDED:
+ case PTP_SYS_OFFSET_EXTENDED2: {
+ struct ptp_system_timestamp sts;
+ struct timespec64 ts;
+
if (!ptp->info->gettimex64) {
err = -EOPNOTSUPP;
break;
@@ -211,8 +251,8 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
extoff = NULL;
break;
}
- if (extoff->n_samples > PTP_MAX_SAMPLES
- || extoff->rsv[0] || extoff->rsv[1] || extoff->rsv[2]) {
+ if (extoff->n_samples > PTP_MAX_SAMPLES ||
+ extoff->rsv[0] || extoff->rsv[1] || extoff->rsv[2]) {
err = -EINVAL;
break;
}
@@ -230,8 +270,13 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
if (copy_to_user((void __user *)arg, extoff, sizeof(*extoff)))
err = -EFAULT;
break;
+ }
case PTP_SYS_OFFSET:
+ case PTP_SYS_OFFSET2: {
+ struct timespec64 ts;
+ struct ptp_clock_time *pct;
+
sysoff = memdup_user((void __user *)arg, sizeof(*sysoff));
if (IS_ERR(sysoff)) {
err = PTR_ERR(sysoff);
@@ -264,12 +309,27 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
if (copy_to_user((void __user *)arg, sysoff, sizeof(*sysoff)))
err = -EFAULT;
break;
+ }
+
+ case PTP_PIN_GETFUNC2: {
+ struct ptp_pin_desc pd;
- case PTP_PIN_GETFUNC:
if (copy_from_user(&pd, (void __user *)arg, sizeof(pd))) {
err = -EFAULT;
break;
}
+ if (cmd == PTP_PIN_GETFUNC2 &&
+ (pd.rsv[0] || pd.rsv[1] || pd.rsv[2] || pd.rsv[3] ||
+ pd.rsv[4])) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_PIN_GETFUNC) {
+ pd.rsv[0] = 0;
+ pd.rsv[1] = 0;
+ pd.rsv[2] = 0;
+ pd.rsv[3] = 0;
+ pd.rsv[4] = 0;
+ }
pin_index = pd.index;
if (pin_index >= ops->n_pins) {
err = -EINVAL;
@@ -283,12 +343,27 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
if (!err && copy_to_user((void __user *)arg, &pd, sizeof(pd)))
err = -EFAULT;
break;
+ }
+
+ case PTP_PIN_SETFUNC2: {
+ struct ptp_pin_desc pd;
- case PTP_PIN_SETFUNC:
if (copy_from_user(&pd, (void __user *)arg, sizeof(pd))) {
err = -EFAULT;
break;
}
+ if (cmd == PTP_PIN_SETFUNC2 &&
+ (pd.rsv[0] || pd.rsv[1] || pd.rsv[2] || pd.rsv[3] ||
+ pd.rsv[4])) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_PIN_SETFUNC) {
+ pd.rsv[0] = 0;
+ pd.rsv[1] = 0;
+ pd.rsv[2] = 0;
+ pd.rsv[3] = 0;
+ pd.rsv[4] = 0;
+ }
pin_index = pd.index;
if (pin_index >= ops->n_pins) {
err = -EINVAL;
@@ -300,6 +375,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
err = ptp_set_pinfunc(ptp, pin_index, pd.func, pd.chan);
mutex_unlock(&ptp->pincfg_mux);
break;
+ }
default:
err = -ENOTTY;
^ permalink raw reply related
* linux-next: Fixes tag needs some work in the net tree
From: Stephen Rothwell @ 2019-08-18 21:33 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Vasundhara Volam, Michael Chan
[-- Attachment #1: Type: text/plain, Size: 393 bytes --]
Hi all,
In commit
dd2ebf3404c7 ("bnxt_en: Fix handling FRAG_ERR when NVM_INSTALL_UPDATE cmd fails")
Fixes tag
Fixes: cb4d1d626145 ("bnxt_en: Retry failed NVM_INSTALL_UPDATE with defragmentation flag enabled.")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: hns: add phy_attached_info() to the hns driver
From: David Miller @ 2019-08-18 21:22 UTC (permalink / raw)
To: liuyonglong
Cc: netdev, linux-kernel, linuxarm, salil.mehta, yisen.zhuang,
shiju.jose
In-Reply-To: <1566008477-16554-1-git-send-email-liuyonglong@huawei.com>
From: Yonglong Liu <liuyonglong@huawei.com>
Date: Sat, 17 Aug 2019 10:21:17 +0800
> This patch adds the call to phy_attached_info() to the hns driver
> to identify which exact PHY drivers is in use.
>
> Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
> Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ravb: Fix use-after-free ravb_tstamp_skb
From: David Miller @ 2019-08-18 21:19 UTC (permalink / raw)
To: horms+renesas; +Cc: netdev
In-Reply-To: <20190816151702.2677-1-horms+renesas@verge.net.au>
From: Simon Horman <horms+renesas@verge.net.au>
Date: Fri, 16 Aug 2019 17:17:02 +0200
> From: Tho Vu <tho.vu.wh@rvc.renesas.com>
>
> When a Tx timestamp is requested, a pointer to the skb is stored in the
> ravb_tstamp_skb struct. This was done without an skb_get. There exists
> the possibility that the skb could be freed by ravb_tx_free (when
> ravb_tx_free is called from ravb_start_xmit) before the timestamp was
> processed, leading to a use-after-free bug.
>
> Use skb_get when filling a ravb_tstamp_skb struct, and add appropriate
> frees/consumes when a ravb_tstamp_skb struct is freed.
>
> Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
> Signed-off-by: Tho Vu <tho.vu.wh@rvc.renesas.com>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> As this is an old bug I am submitting a fix against net-next rather than
> net: I do not see any urgency here. I am however, happy for it to be
> applied against net instead.
Applied to 'net', thanks Simon.
^ permalink raw reply
* Re: [PATCH net-next 4/4 v3] net: ethernet: mediatek: Add MT7628/88 SoC support
From: David Miller @ 2019-08-18 21:17 UTC (permalink / raw)
To: sr; +Cc: netdev, linux-mediatek, opensource, daniel, sean.wang, john
In-Reply-To: <20190816132325.28426-4-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Fri, 16 Aug 2019 15:23:25 +0200
> This patch adds support for the MediaTek MT7628/88 SoCs to the common
> MediaTek ethernet driver. Some minor changes are needed for this and
> a bigger change, as the MT7628 does not support QDMA (only PDMA).
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
Please submit your patch series properly next time, which means including
a "[PATCH 0/N]" introductory posting which explains what the patch series
is doing, how it is doing it, and why it is doing it that way.
It not only provides a proper organizational object for your patch series,
it also makes less work for me because I can just reply to that single email
when I apply your series instead of having to reply to every single one
in the set.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/4 v3] net: ethernet: mediatek: Rename NEXT_RX_DESP_IDX to NEXT_DESP_IDX
From: David Miller @ 2019-08-18 21:16 UTC (permalink / raw)
To: sr; +Cc: netdev, linux-mediatek, opensource, daniel, sean.wang, john
In-Reply-To: <20190816132325.28426-3-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Fri, 16 Aug 2019 15:23:24 +0200
> Rename the NEXT_RX_DESP_IDX macro to NEXT_DESP_IDX, so that it better
> can be used for TX ops as well. This will be used in the upcoming
> MT7628/88 support (same functionality for RX and TX in this macro).
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4 v3] net: ethernet: mediatek: Rename MTK_QMTK_INT_STATUS to MTK_QDMA_INT_STATUS
From: David Miller @ 2019-08-18 21:16 UTC (permalink / raw)
To: sr; +Cc: netdev, linux-mediatek, opensource, daniel, sean.wang, john
In-Reply-To: <20190816132325.28426-2-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Fri, 16 Aug 2019 15:23:23 +0200
> Currently all QDMA registers are named "MTK_QDMA_foo" in this driver
> with one exception: MTK_QMTK_INT_STATUS. This patch renames
> MTK_QMTK_INT_STATUS to MTK_QDMA_INT_STATUS so that all macros follow
> this rule.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/4 v3] dt-bindings: net: mediatek: Add support for MediaTek MT7628/88 SoC
From: David Miller @ 2019-08-18 21:16 UTC (permalink / raw)
To: sr
Cc: netdev, linux-mediatek, opensource, daniel, sean.wang, john,
devicetree, robh
In-Reply-To: <20190816132325.28426-1-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Fri, 16 Aug 2019 15:23:22 +0200
> Add compatible for the ethernet IP core on MT7628/88 SoCs. Its
> compatible with the older Ralink Rt5350F SoC. And OpenWrt already
> uses this compatible string for the MT76x8.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
^ permalink raw reply
* Re: [PATCH] be2net: eliminate enable field from be_aic_obj
From: David Miller @ 2019-08-18 21:14 UTC (permalink / raw)
To: ivecera; +Cc: netdev, sathya.perla, poros, sriharsha.basavapatna
In-Reply-To: <20190816071535.28349-1-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Fri, 16 Aug 2019 09:15:35 +0200
> Adaptive coalescing is managed per adapter not per event queue so it
> does not needed to store 'enable' flag for each event queue.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net,v5 0/2] flow_offload hardware priority fixes
From: David Miller @ 2019-08-18 21:13 UTC (permalink / raw)
To: pablo
Cc: netfilter-devel, netdev, marcelo.leitner, jiri, wenxu, saeedm,
paulb, gerlitz.or, jakub.kicinski
In-Reply-To: <20190816012410.31844-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 16 Aug 2019 03:24:08 +0200
> This patchset contains two updates for the flow_offload users:
>
> 1) Pass the major tc priority to drivers so they do not have to
> lshift it. This is a preparation patch for the fix coming in
> patch #2.
>
> 2) Set the hardware priority from the netfilter basechain priority,
> some drivers break when using the existing hardware priority
> number that is set to zero.
>
> v5: fix patch 2/2 to address a clang warning and to simplify
> the priority mapping.
Series applied.
^ permalink raw reply
* Re: [PATCH v2] wimax/i2400m: fix a memory leak bug
From: David Miller @ 2019-08-18 21:11 UTC (permalink / raw)
To: wenwen; +Cc: inaky.perez-gonzalez, linux-wimax, netdev, linux-kernel
In-Reply-To: <1565900991-3573-1-git-send-email-wenwen@cs.uga.edu>
From: Wenwen Wang <wenwen@cs.uga.edu>
Date: Thu, 15 Aug 2019 15:29:51 -0500
> In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
> to hold the original command line options. Then, the options are parsed.
> However, if an error occurs during the parsing process, 'options_orig' is
> not deallocated, leading to a memory leak bug. To fix this issue, free
> 'options_orig' before returning the error.
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Applied, but... looking at the rest of this file I hope nobody is actually
running this code.
^ permalink raw reply
* Re: [PATCH] net: cavium: fix driver name
From: David Miller @ 2019-08-18 21:02 UTC (permalink / raw)
To: stephen; +Cc: yuehaibing, netdev
In-Reply-To: <20190815194949.10630-1-stephen@networkplumber.org>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 15 Aug 2019 12:49:49 -0700
> The driver name gets exposed in sysfs under /sys/bus/pci/drivers
> so it should look like other devices. Change it to be common
> format (instead of "Cavium PTP").
>
> This is a trivial fix that was observed by accident because
> Debian kernels were building this driver into kernel (bug).
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [net-next v2 1/1] tipc: clean up skb list lock handling on send path
From: David Miller @ 2019-08-18 21:01 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, tung.q.nguyen, hoang.h.le, lxin, shuali, ying.xue,
edumazet, tipc-discussion
In-Reply-To: <1565880170-19548-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 15 Aug 2019 16:42:50 +0200
> The policy for handling the skb list locks on the send and receive paths
> is simple.
>
> - On the send path we never need to grab the lock on the 'xmitq' list
> when the destination is an exernal node.
>
> - On the receive path we always need to grab the lock on the 'inputq'
> list, irrespective of source node.
>
> However, when transmitting node local messages those will eventually
> end up on the receive path of a local socket, meaning that the argument
> 'xmitq' in tipc_node_xmit() will become the 'ínputq' argument in the
> function tipc_sk_rcv(). This has been handled by always initializing
> the spinlock of the 'xmitq' list at message creation, just in case it
> may end up on the receive path later, and despite knowing that the lock
> in most cases never will be used.
>
> This approach is inaccurate and confusing, and has also concealed the
> fact that the stated 'no lock grabbing' policy for the send path is
> violated in some cases.
>
> We now clean up this by never initializing the lock at message creation,
> instead doing this at the moment we find that the message actually will
> enter the receive path. At the same time we fix the four locations
> where we incorrectly access the spinlock on the send/error path.
>
> This patch also reverts commit d12cffe9329f ("tipc: ensure head->lock
> is initialised") which has now become redundant.
>
> CC: Eric Dumazet <edumazet@google.com>
> Reported-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Unmap DMA address of TX descriptor buffers after use
From: David Miller @ 2019-08-18 20:58 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1565812625-24364-1-git-send-email-tlfalcon@linux.ibm.com>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
Date: Wed, 14 Aug 2019 14:57:05 -0500
> There's no need to wait until a completion is received to unmap
> TX descriptor buffers that have been passed to the hypervisor.
> Instead unmap it when the hypervisor call has completed. This patch
> avoids the possibility that a buffer will not be unmapped because
> a TX completion is lost or mishandled.
>
> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
> Tested-by: Devesh K. Singh <devesh_singh@in.ibm.com>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] PTP: introduce new versions of IOCTLs
From: Richard Cochran @ 2019-08-18 20:11 UTC (permalink / raw)
To: Joe Perches; +Cc: Felipe Balbi, Christopher S Hall, netdev, linux-kernel
In-Reply-To: <a146c1356b4272c481e5cc63666c6e58b8442407.camel@perches.com>
On Sat, Aug 17, 2019 at 09:17:20AM -0700, Joe Perches wrote:
> Is there a case where this initialization is
> unnecessary such that it impacts performance
> given the use in ptp_ioctl?
None of these ioctls are sensitive WRT performance. They are all
setup or configuration, or in the case of the OFFSET ioctls, the tiny
extra delay before the actual measurement will not affect the result.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net 0/6] bnxt_en: Bug fixes.
From: David Miller @ 2019-08-18 20:06 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1565994817-6328-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 16 Aug 2019 18:33:31 -0400
> 2 Bug fixes related to 57500 shutdown sequence and doorbell sequence,
> 2 TC Flower bug fixes related to the setting of the flow direction,
> 1 NVRAM update bug fix, and a minor fix to suppress an unnecessary
> error message. Please queue for -stable as well. Thanks.
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: kalmia: fix memory leaks
From: David Miller @ 2019-08-18 20:03 UTC (permalink / raw)
To: wenwen; +Cc: gregkh, allison, tglx, linux-usb, netdev, linux-kernel
In-Reply-To: <1565809005-8437-1-git-send-email-wenwen@cs.uga.edu>
From: Wenwen Wang <wenwen@cs.uga.edu>
Date: Wed, 14 Aug 2019 13:56:43 -0500
> In kalmia_init_and_get_ethernet_addr(), 'usb_buf' is allocated through
> kmalloc(). In the following execution, if the 'status' returned by
> kalmia_send_init_packet() is not 0, 'usb_buf' is not deallocated, leading
> to memory leaks. To fix this issue, add the 'out' label to free 'usb_buf'.
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Applied.
^ permalink raw reply
* Re: [PATCH] cx82310_eth: fix a memory leak bug
From: David Miller @ 2019-08-18 20:02 UTC (permalink / raw)
To: wenwen
Cc: tglx, swinslow, opensource, kstewart, linux-usb, netdev,
linux-kernel
In-Reply-To: <1565805819-8113-1-git-send-email-wenwen@cs.uga.edu>
From: Wenwen Wang <wenwen@cs.uga.edu>
Date: Wed, 14 Aug 2019 13:03:38 -0500
> In cx82310_bind(), 'dev->partial_data' is allocated through kmalloc().
> Then, the execution waits for the firmware to become ready. If the firmware
> is not ready in time, the execution is terminated. However, the allocated
> 'dev->partial_data' is not deallocated on this path, leading to a memory
> leak bug. To fix this issue, free 'dev->partial_data' before returning the
> error.
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: hns3: add some cleanups & bugfix
From: David Miller @ 2019-08-18 19:59 UTC (permalink / raw)
To: tanhuazhong
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski
In-Reply-To: <1565942982-12105-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Fri, 16 Aug 2019 16:09:36 +0800
> This patch-set includes cleanups and bugfix for the HNS3 ethernet
> controller driver.
>
> [patch 01/06 - 03/06] adds some cleanups.
>
> [patch 04/06] changes the print level of RAS.
>
> [patch 05/06] fixes a bug related to MAC TNL.
>
> [patch 06/06] adds phy_attached_info().
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 1/1] bnx2x: Fix VF's VLAN reconfiguration in reload.
From: David Miller @ 2019-08-18 19:45 UTC (permalink / raw)
To: manishc; +Cc: netdev, aelior, skalluru
In-Reply-To: <20190818142548.22365-1-manishc@marvell.com>
From: Manish Chopra <manishc@marvell.com>
Date: Sun, 18 Aug 2019 07:25:48 -0700
> Commit 04f05230c5c13 ("bnx2x: Remove configured vlans as
> part of unload sequence."), introduced a regression in driver
> that as a part of VF's reload flow, VLANs created on the VF
> doesn't get re-configured in hardware as vlan metadata/info
> was not getting cleared for the VFs which causes vlan PING to stop.
>
> This patch clears the vlan metadata/info so that VLANs gets
> re-configured back in the hardware in VF's reload flow and
> PING/traffic continues for VLANs created over the VFs.
>
> Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload sequence.")
> Signed-off-by: Manish Chopra <manishc@marvell.com>
> Signed-off-by: Sudarsana Kalluru <skalluru@marvell.com>
> Signed-off-by: Shahed Shaikh <shshaikh@marvell.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH iproute2-next v2 0/4] Add devlink-trap support
From: David Ahern @ 2019-08-18 18:51 UTC (permalink / raw)
To: Ido Schimmel, netdev; +Cc: stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813083143.13509-1-idosch@idosch.org>
On 8/13/19 2:31 AM, Ido Schimmel wrote:
> From: Ido Schimmel <idosch@mellanox.com>
>
> This patchset adds devlink-trap support in iproute2.
>
> Patch #1 increases the number of options devlink can handle.
>
> Patches #2-#3 gradually add support for all devlink-trap commands.
>
> Patch #4 adds a man page for devlink-trap.
>
> See individual commit messages for example usage and output.
>
> Changes in v2:
> * Remove report option and monitor command since monitoring is done
> using drop monitor
>
> Ido Schimmel (4):
> devlink: Increase number of supported options
> devlink: Add devlink trap set and show commands
> devlink: Add devlink trap group set and show commands
> devlink: Add man page for devlink-trap
>
> devlink/devlink.c | 448 +++++++++++++++++++++++++++++++++++--
> man/man8/devlink-monitor.8 | 3 +-
> man/man8/devlink-trap.8 | 138 ++++++++++++
> man/man8/devlink.8 | 11 +-
> 4 files changed, 581 insertions(+), 19 deletions(-)
> create mode 100644 man/man8/devlink-trap.8
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: kernel BUG at net/rxrpc/local_object.c:LINE!
From: syzbot @ 2019-08-18 18:47 UTC (permalink / raw)
To: davem, dhowells, dvyukov, ebiggers, linux-afs, linux-kernel,
netdev, syzkaller-bugs
In-Reply-To: <0000000000004c2416058c594b30@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 0c3d3d64 Add linux-next specific files for 20190816
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=108b58f2600000
kernel config: https://syzkaller.appspot.com/x/.config?x=dffdf1e146f941f4
dashboard link: https://syzkaller.appspot.com/bug?extid=1e0edc4b8b7494c28450
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13feb73c600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=127088f2600000
The bug was bisected to:
commit 46894a13599a977ac35411b536fb3e0b2feefa95
Author: David Howells <dhowells@redhat.com>
Date: Thu Oct 4 08:32:28 2018 +0000
rxrpc: Use IPv4 addresses throught the IPv6
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=152fabe3a00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=172fabe3a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=132fabe3a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1e0edc4b8b7494c28450@syzkaller.appspotmail.com
Fixes: 46894a13599a ("rxrpc: Use IPv4 addresses throught the IPv6")
rxrpc: Assertion failed
------------[ cut here ]------------
kernel BUG at net/rxrpc/local_object.c:433!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc4-next-20190816 #67
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: krxrpcd rxrpc_local_processor
RIP: 0010:rxrpc_local_destroyer net/rxrpc/local_object.c:433 [inline]
RIP: 0010:rxrpc_local_processor.cold+0x24/0x29 net/rxrpc/local_object.c:466
Code: df a1 bc fa 0f 0b e8 c4 2b d3 fa 48 c7 c7 e0 24 5b 88 e8 cc a1 bc fa
0f 0b e8 b1 2b d3 fa 48 c7 c7 e0 24 5b 88 e8 b9 a1 bc fa <0f> 0b 90 90 90
55 48 89 e5 41 57 49 89 ff 41 56 41 55 41 54 53 48
RSP: 0018:ffff8880a98d7ce8 EFLAGS: 00010282
RAX: 0000000000000017 RBX: ffff88808c90a978 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815bb906 RDI: ffffed101531af8f
RBP: ffff8880a98d7d30 R08: 0000000000000017 R09: ffffed1015d060d9
R10: ffffed1015d060d8 R11: ffff8880ae8306c7 R12: ffff88808c90a208
R13: ffff88808dc48648 R14: ffff88808c90a940 R15: ffff8880929faa00
FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000049f2b0 CR3: 0000000008e6d000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace c65e44ef4b16c854 ]---
RIP: 0010:rxrpc_local_destroyer net/rxrpc/local_object.c:433 [inline]
RIP: 0010:rxrpc_local_processor.cold+0x24/0x29 net/rxrpc/local_object.c:466
Code: df a1 bc fa 0f 0b e8 c4 2b d3 fa 48 c7 c7 e0 24 5b 88 e8 cc a1 bc fa
0f 0b e8 b1 2b d3 fa 48 c7 c7 e0 24 5b 88 e8 b9 a1 bc fa <0f> 0b 90 90 90
55 48 89 e5 41 57 49 89 ff 41 56 41 55 41 54 53 48
RSP: 0018:ffff8880a98d7ce8 EFLAGS: 00010282
RAX: 0000000000000017 RBX: ffff88808c90a978 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815bb906 RDI: ffffed101531af8f
RBP: ffff8880a98d7d30 R08: 0000000000000017 R09: ffffed1015d060d9
R10: ffffed1015d060d8 R11: ffff8880ae8306c7 R12: ffff88808c90a208
R13: ffff88808dc48648 R14: ffff88808c90a940 R15: ffff8880929faa00
FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600400 CR3: 000000009b982000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
^ permalink raw reply
* Re: [PATCH 2/2] ip nexthop: Allow flush|list operations to specify a specific protocol
From: David Ahern @ 2019-08-18 18:31 UTC (permalink / raw)
To: Donald Sharp, netdev
In-Reply-To: <20190810001843.32068-3-sharpd@cumulusnetworks.com>
On 8/9/19 6:18 PM, Donald Sharp wrote:
> In the case where we have a large number of nexthops from a specific
> protocol, allow the flush and list operations to take a protocol
> to limit the commands scopes.
>
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> ip/ipnexthop.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
Donald: This looks correct to me. Before applying I want to add test
cases to tools/testing/selftests/net/fib_nexthops.sh in the kernel repo
to just to run through different options. Hopefully, I can do that this
week.
^ permalink raw reply
* [PATCH spi for-5.4 2/5] spi: Add a PTP system timestamp to the transfer structure
From: Vladimir Oltean @ 2019-08-18 18:25 UTC (permalink / raw)
To: broonie, h.feurstein, mlichvar, richardcochran, andrew,
f.fainelli
Cc: linux-spi, netdev, Vladimir Oltean
In-Reply-To: <20190818182600.3047-1-olteanv@gmail.com>
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc).
Since there are lots of sources of timing jitter when retrieving the
time from such a device (queuing delays, locking contention, running in
interruptible context etc), introduce a PTP system timestamp structure
in struct spi_transfer. This is to be used by SPI device drivers when
they need to know the exact time at which the underlying device's time
was snapshotted.
Because SPI controllers may have jitter even between frames, also
introduce a field which specifies to the controller driver specifically
which byte needs to be snapshotted.
Add a default implementation of the PTP system timestamping in the SPI
core. There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
drivers/spi/spi.c | 62 +++++++++++++++++++++++++++++++++++++++++
include/linux/spi/spi.h | 38 +++++++++++++++++++++++++
2 files changed, 100 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index d96e04627982..cf5c5435edcd 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1171,6 +1171,11 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,
spi_statistics_add_transfer_stats(statm, xfer, ctlr);
spi_statistics_add_transfer_stats(stats, xfer, ctlr);
+ if (!ctlr->ptp_sts_supported) {
+ xfer->ptp_sts_word_pre = 0;
+ ptp_read_system_prets(xfer->ptp_sts);
+ }
+
if (xfer->tx_buf || xfer->rx_buf) {
reinit_completion(&ctlr->xfer_completion);
@@ -1197,6 +1202,11 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,
xfer->len);
}
+ if (!ctlr->ptp_sts_supported) {
+ ptp_read_system_postts(xfer->ptp_sts);
+ xfer->ptp_sts_word_post = xfer->len;
+ }
+
trace_spi_transfer_stop(msg, xfer);
if (msg->status != -EINPROGRESS)
@@ -1265,6 +1275,7 @@ EXPORT_SYMBOL_GPL(spi_finalize_current_transfer);
*/
static void __spi_pump_messages(struct spi_controller *ctlr, bool in_kthread)
{
+ struct spi_transfer *xfer;
struct spi_message *mesg;
bool was_busy = false;
unsigned long flags;
@@ -1391,6 +1402,13 @@ static void __spi_pump_messages(struct spi_controller *ctlr, bool in_kthread)
goto out;
}
+ if (!ctlr->ptp_sts_supported) {
+ list_for_each_entry(xfer, &mesg->transfers, transfer_list) {
+ xfer->ptp_sts_word_pre = 0;
+ ptp_read_system_prets(xfer->ptp_sts);
+ }
+ }
+
ret = ctlr->transfer_one_message(ctlr, mesg);
if (ret) {
dev_err(&ctlr->dev,
@@ -1418,6 +1436,34 @@ static void spi_pump_messages(struct kthread_work *work)
__spi_pump_messages(ctlr, true);
}
+/**
+ * spi_xfer_ptp_sts_word - helper for drivers to retrieve the pointer to the
+ * word in the TX buffer which must be timestamped.
+ * The SPI slave does not provide a pointer directly
+ * because the TX and RX buffers may be reallocated
+ * (see @spi_map_msg).
+ * @xfer: Pointer to the transfer being timestamped
+ * @pre: If true, returns the pointer to @ptp_sts_word_pre, otherwise returns
+ * the pointer to @ptp_sts_word_post.
+ */
+const void *spi_xfer_ptp_sts_word(struct spi_transfer *xfer, bool pre)
+{
+ unsigned int bytes_per_word;
+
+ if (xfer->bits_per_word <= 8)
+ bytes_per_word = 1;
+ else if (xfer->bits_per_word <= 16)
+ bytes_per_word = 2;
+ else
+ bytes_per_word = 4;
+
+ if (pre)
+ return xfer->tx_buf + xfer->ptp_sts_word_pre * bytes_per_word;
+
+ return xfer->tx_buf + xfer->ptp_sts_word_post * bytes_per_word;
+}
+EXPORT_SYMBOL_GPL(spi_xfer_ptp_sts_word);
+
/**
* spi_set_thread_rt - set the controller to pump at realtime priority
* @ctlr: controller to boost priority of
@@ -1503,6 +1549,7 @@ EXPORT_SYMBOL_GPL(spi_get_next_queued_message);
*/
void spi_finalize_current_message(struct spi_controller *ctlr)
{
+ struct spi_transfer *xfer;
struct spi_message *mesg;
unsigned long flags;
int ret;
@@ -1511,6 +1558,13 @@ void spi_finalize_current_message(struct spi_controller *ctlr)
mesg = ctlr->cur_msg;
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
+ if (!ctlr->ptp_sts_supported) {
+ list_for_each_entry(xfer, &mesg->transfers, transfer_list) {
+ ptp_read_system_postts(xfer->ptp_sts);
+ xfer->ptp_sts_word_post = xfer->len;
+ }
+ }
+
spi_unmap_msg(ctlr, mesg);
if (ctlr->cur_msg_prepared && ctlr->unprepare_message) {
@@ -3270,6 +3324,7 @@ static int __spi_validate(struct spi_device *spi, struct spi_message *message)
static int __spi_async(struct spi_device *spi, struct spi_message *message)
{
struct spi_controller *ctlr = spi->controller;
+ struct spi_transfer *xfer;
/*
* Some controllers do not support doing regular SPI transfers. Return
@@ -3285,6 +3340,13 @@ static int __spi_async(struct spi_device *spi, struct spi_message *message)
trace_spi_message_submit(message);
+ if (!ctlr->ptp_sts_supported) {
+ list_for_each_entry(xfer, &message->transfers, transfer_list) {
+ xfer->ptp_sts_word_pre = 0;
+ ptp_read_system_prets(xfer->ptp_sts);
+ }
+ }
+
return ctlr->transfer(spi, message);
}
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index af4f265d0f67..bb7553c6e5d0 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -13,6 +13,7 @@
#include <linux/completion.h>
#include <linux/scatterlist.h>
#include <linux/gpio/consumer.h>
+#include <linux/ptp_clock_kernel.h>
struct dma_chan;
struct property_entry;
@@ -409,6 +410,12 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
* @fw_translate_cs: If the boot firmware uses different numbering scheme
* what Linux expects, this optional hook can be used to translate
* between the two.
+ * @ptp_sts_supported: If the driver sets this to true, it must provide a
+ * time snapshot in @spi_transfer->ptp_sts as close as possible to the
+ * moment in time when @spi_transfer->ptp_sts_word_pre and
+ * @spi_transfer->ptp_sts_word_post were transmitted.
+ * If the driver does not set this, the SPI core takes the snapshot as
+ * close to the driver hand-over as possible.
*
* Each SPI controller can communicate with one or more @spi_device
* children. These make a small bus, sharing MOSI, MISO and SCK signals
@@ -604,6 +611,12 @@ struct spi_controller {
void *dummy_tx;
int (*fw_translate_cs)(struct spi_controller *ctlr, unsigned cs);
+
+ /*
+ * Driver sets this field to indicate it is able to snapshot SPI
+ * transfers (needed e.g. for reading the time of POSIX clocks)
+ */
+ bool ptp_sts_supported;
};
static inline void *spi_controller_get_devdata(struct spi_controller *ctlr)
@@ -644,6 +657,9 @@ extern struct spi_message *spi_get_next_queued_message(struct spi_controller *ct
extern void spi_finalize_current_message(struct spi_controller *ctlr);
extern void spi_finalize_current_transfer(struct spi_controller *ctlr);
+/* Helper calls for driver to get which buffer pointer must be timestamped */
+extern const void *spi_xfer_ptp_sts_word(struct spi_transfer *xfer, bool pre);
+
/* the spi driver core manages memory for the spi_controller classdev */
extern struct spi_controller *__spi_alloc_controller(struct device *host,
unsigned int size, bool slave);
@@ -753,6 +769,24 @@ extern void spi_res_release(struct spi_controller *ctlr,
* @transfer_list: transfers are sequenced through @spi_message.transfers
* @tx_sg: Scatterlist for transmit, currently not for client use
* @rx_sg: Scatterlist for receive, currently not for client use
+ * @ptp_sts_word_pre: The word (subject to bits_per_word semantics) offset
+ * within @tx_buf for which the SPI device is requesting that the time
+ * snapshot for this transfer begins. Upon completing the SPI transfer,
+ * this value may have changed compared to what was requested, depending
+ * on the available snapshotting resolution (DMA transfer,
+ * @ptp_sts_supported is false, etc).
+ * @ptp_sts_word_post: See @ptp_sts_word_post. The two can be equal (meaning
+ * that a single byte should be snapshotted). The core will set
+ * @ptp_sts_word_pre to 0, and @ptp_sts_word_post to the length of the
+ * transfer, if @ptp_sts_supported is false for this controller. This is
+ * done purposefully (instead of setting to spi_transfer->len - 1) to
+ * denote that a transfer-level snapshot taken from within the driver may
+ * still be of higher quality.
+ * @ptp_sts: Pointer to a memory location held by the SPI slave device where a
+ * PTP system timestamp structure may lie. If drivers use PIO or their
+ * hardware has some sort of assist for retrieving exact transfer timing,
+ * they can (and should) assert @ptp_sts_supported and populate this
+ * structure using the ptp_read_system_*ts helper functions.
*
* SPI transfers always write the same number of bytes as they read.
* Protocol drivers should always provide @rx_buf and/or @tx_buf.
@@ -842,6 +876,10 @@ struct spi_transfer {
u32 effective_speed_hz;
+ unsigned int ptp_sts_word_pre;
+ unsigned int ptp_sts_word_post;
+ struct ptp_system_timestamp *ptp_sts;
+
struct list_head transfer_list;
};
--
2.17.1
^ permalink raw reply related
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