* Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
From: Arnd Bergmann @ 2017-06-02 10:51 UTC (permalink / raw)
To: Yan, Zheng
Cc: yuchao0-hv44wF8Li93QT0dZR+AlfA, J. Bruce Fields, Chris Mason,
linux-mtd, Deepa Dinamani, Evgeniy Dushistov, Jeff Layton,
ceph-devel, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-cifs-u79uwXL29TY76Z2rM5mHXA, Paul Moore, y2038 Mailman List,
Ingo Molnar, Steven Rostedt, Drokin, Oleg, John Stultz, Al Viro,
David Sterba, Jaegeuk Kim, Thomas Gleixner, Josef Bacik, gregkh,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ, Linux Kernel Mailing List,
Eric
In-Reply-To: <CAAM7YA=BJHFLz_Ud==7L=yCzxj+1sjctc68tvpNogPhiSxxELQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> I believe the bug you see is the result of the two timestamps
>> currently being almost guaranteed to be different in the latest
>> kernels.
>> Changing r_stamp to use current_kernel_time() will make it the
>> same value most of the time (as it was before Deepa's patch),
>> but when the timer interrupt happens between the timestamps,
>> the two are still different, it's just much harder to hit.
>>
>> I think the proper solution should be to change __ceph_setattr()
>> in a way that has req->r_stamp always synchronized with i_ctime.
>> If we copy i_ctime to r_stamp, that will also take care of the
>> future issues with the planned changes to current_time().
>>
> I already have a patch
> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
Looks good to me. In case anyone cares:
Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>> The part I don't understand is what else r_stamp (i.e. the time
>> stamp in ceph_msg_data with type==
>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>> ctime in CEPH_MDS_OP_SETATTR.
>>
>> Will this be used to update the stored i_ctime for other operations
>> too? If so, we would need to synchronize it with the in-memory
>> i_ctime for all operations that do this.
>>
>
> yes, mds uses it to update ctime of modified inodes. For example,
> when handling mkdir, mds set ctime of both parent inode and new inode
> to r_stamp.
I see, so we may have a variation of that problem there as well: From
my reading of the code, the child inode is not in memory yet, so
that seems fine, but I could not find where the parent in-memory inode
i_ctime is updated in ceph, but it is most likely not the same as
req->r_stamp (assuming it gets updated at all).
Would it make sense require all callers of ceph_mdsc_do_request()
to update r_stamp at the same time as i_ctime to keep them in sync?
Arnd
^ permalink raw reply
* [PATCH] net: phy: marvell: make two functions static
From: Colin King @ 2017-06-02 11:14 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, netdev, linux-kernel; +Cc: kernel-janitors
From: Colin Ian King <colin.king@canonical.com>
functions m88e1510_get_temp_critical and m88e1510_get_temp_alarm can be
made static as they not need to be in global scope.
Cleans up sparse warnings:
"symbol 'm88e1510_get_temp_alarm' was not declared. Should it be static?"
"symbol 'm88e1510_get_temp_critical' was not declared. Should it be
static?"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/phy/marvell.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 7c2cde45c262..dc679cdf96be 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1704,7 +1704,7 @@ static int m88e1510_get_temp(struct phy_device *phydev, long *temp)
return ret;
}
-int m88e1510_get_temp_critical(struct phy_device *phydev, long *temp)
+static int m88e1510_get_temp_critical(struct phy_device *phydev, long *temp)
{
int oldpage;
int ret;
@@ -1735,7 +1735,7 @@ int m88e1510_get_temp_critical(struct phy_device *phydev, long *temp)
return ret;
}
-int m88e1510_set_temp_critical(struct phy_device *phydev, long temp)
+static int m88e1510_set_temp_critical(struct phy_device *phydev, long temp)
{
int oldpage;
int ret;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
From: Yan, Zheng @ 2017-06-02 11:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: yuchao0, J. Bruce Fields, Chris Mason, linux-mtd, Deepa Dinamani,
Evgeniy Dushistov, Jeff Layton, ceph-devel, devel, linux-cifs,
Paul Moore, y2038 Mailman List, Ingo Molnar, Steven Rostedt,
Drokin, Oleg, John Stultz, Al Viro, David Sterba, Jaegeuk Kim,
Thomas Gleixner, Dilger, Andreas, Josef Bacik, gregkh,
samba-technical, Linux
In-Reply-To: <CAK8P3a0D3EXuwBj+sSVL9cmpysdvQWXnkE0zEctBJS8XOqhX7A@mail.gmail.com>
On Fri, Jun 2, 2017 at 6:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>
>>> I believe the bug you see is the result of the two timestamps
>>> currently being almost guaranteed to be different in the latest
>>> kernels.
>>> Changing r_stamp to use current_kernel_time() will make it the
>>> same value most of the time (as it was before Deepa's patch),
>>> but when the timer interrupt happens between the timestamps,
>>> the two are still different, it's just much harder to hit.
>>>
>>> I think the proper solution should be to change __ceph_setattr()
>>> in a way that has req->r_stamp always synchronized with i_ctime.
>>> If we copy i_ctime to r_stamp, that will also take care of the
>>> future issues with the planned changes to current_time().
>>>
>> I already have a patch
>> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
>
> Looks good to me. In case anyone cares:
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
>>> The part I don't understand is what else r_stamp (i.e. the time
>>> stamp in ceph_msg_data with type==
>>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>>> ctime in CEPH_MDS_OP_SETATTR.
>>>
>>> Will this be used to update the stored i_ctime for other operations
>>> too? If so, we would need to synchronize it with the in-memory
>>> i_ctime for all operations that do this.
>>>
>>
>> yes, mds uses it to update ctime of modified inodes. For example,
>> when handling mkdir, mds set ctime of both parent inode and new inode
>> to r_stamp.
>
> I see, so we may have a variation of that problem there as well: From
> my reading of the code, the child inode is not in memory yet, so
> that seems fine, but I could not find where the parent in-memory inode
> i_ctime is updated in ceph, but it is most likely not the same as
> req->r_stamp (assuming it gets updated at all).
i_ctime is updated when handling request reply, by ceph_fill_file_time().
__ceph_setattr() can update the in-memory inode's ctime after request
reply is received. The difference between ktime_get_real_ts() and
current_time() can be larger than round-trip time of request. So it's
still possible that __ceph_setattr() make ctime go back.
Regards
Yan, Zheng
>
> Would it make sense require all callers of ceph_mdsc_do_request()
> to update r_stamp at the same time as i_ctime to keep them in sync?
>
> Arnd
^ permalink raw reply
* Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
From: Arnd Bergmann @ 2017-06-02 11:33 UTC (permalink / raw)
To: Yan, Zheng
Cc: yuchao0-hv44wF8Li93QT0dZR+AlfA, J. Bruce Fields, Chris Mason,
linux-mtd, Deepa Dinamani, Evgeniy Dushistov, Jeff Layton,
ceph-devel, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-cifs-u79uwXL29TY76Z2rM5mHXA, Paul Moore, y2038 Mailman List,
Ingo Molnar, Steven Rostedt, Drokin, Oleg, John Stultz, Al Viro,
David Sterba, Jaegeuk Kim, Thomas Gleixner, Josef Bacik, gregkh,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ, Linux Kernel Mailing List,
Eric
In-Reply-To: <CAAM7YAk8JNU=XV=sOCczagWjBimO4JSPU08th7E4u6FTJN--9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Jun 2, 2017 at 1:18 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Jun 2, 2017 at 6:51 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>
>>>> I believe the bug you see is the result of the two timestamps
>>>> currently being almost guaranteed to be different in the latest
>>>> kernels.
>>>> Changing r_stamp to use current_kernel_time() will make it the
>>>> same value most of the time (as it was before Deepa's patch),
>>>> but when the timer interrupt happens between the timestamps,
>>>> the two are still different, it's just much harder to hit.
>>>>
>>>> I think the proper solution should be to change __ceph_setattr()
>>>> in a way that has req->r_stamp always synchronized with i_ctime.
>>>> If we copy i_ctime to r_stamp, that will also take care of the
>>>> future issues with the planned changes to current_time().
>>>>
>>> I already have a patch
>>> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
>>
>> Looks good to me. In case anyone cares:
>> Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>>
>>>> The part I don't understand is what else r_stamp (i.e. the time
>>>> stamp in ceph_msg_data with type==
>>>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>>>> ctime in CEPH_MDS_OP_SETATTR.
>>>>
>>>> Will this be used to update the stored i_ctime for other operations
>>>> too? If so, we would need to synchronize it with the in-memory
>>>> i_ctime for all operations that do this.
>>>>
>>>
>>> yes, mds uses it to update ctime of modified inodes. For example,
>>> when handling mkdir, mds set ctime of both parent inode and new inode
>>> to r_stamp.
>>
>> I see, so we may have a variation of that problem there as well: From
>> my reading of the code, the child inode is not in memory yet, so
>> that seems fine, but I could not find where the parent in-memory inode
>> i_ctime is updated in ceph, but it is most likely not the same as
>> req->r_stamp (assuming it gets updated at all).
>
> i_ctime is updated when handling request reply, by ceph_fill_file_time().
> __ceph_setattr() can update the in-memory inode's ctime after request
> reply is received. The difference between ktime_get_real_ts() and
> current_time() can be larger than round-trip time of request. So it's
> still possible that __ceph_setattr() make ctime go back.
But the __ceph_setattr() problem should be fixed by your patch, right?
What I meant is another related problem in ceph_mkdir() where the
i_ctime field of the parent inode is different between the persistent
representation in the mds and the in-memory representation.
Arnd
>> Would it make sense require all callers of ceph_mdsc_do_request()
>> to update r_stamp at the same time as i_ctime to keep them in sync?
^ permalink raw reply
* [PATCH] netxen: remove writeq/readq function definitions
From: Corentin Labbe @ 2017-06-02 11:36 UTC (permalink / raw)
To: manish.chopra, rahul.verma, Dept-GELinuxNICDev
Cc: netdev, linux-kernel, Corentin Labbe
Instead of rewriting write/readq, use linux/io-64-nonatomic-lo-hi.h which
already have them.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index a996801d442d..66ff15d08bad 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ -21,6 +21,7 @@
*
*/
+#include <linux/io-64-nonatomic-lo-hi.h>
#include <linux/slab.h>
#include "netxen_nic.h"
#include "netxen_nic_hw.h"
@@ -44,20 +45,6 @@ static void netxen_nic_io_write_128M(struct netxen_adapter *adapter,
void __iomem *addr, u32 data);
static u32 netxen_nic_io_read_128M(struct netxen_adapter *adapter,
void __iomem *addr);
-#ifndef readq
-static inline u64 readq(void __iomem *addr)
-{
- return readl(addr) | (((u64) readl(addr + 4)) << 32LL);
-}
-#endif
-
-#ifndef writeq
-static inline void writeq(u64 val, void __iomem *addr)
-{
- writel(((u32) (val)), (addr));
- writel(((u32) (val >> 32)), (addr + 4));
-}
-#endif
#define PCI_OFFSET_FIRST_RANGE(adapter, off) \
((adapter)->ahw.pci_base0 + (off))
--
2.13.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: David Ahern @ 2017-06-02 11:39 UTC (permalink / raw)
To: Alexei Starovoitov, Jakub Kicinski, Martin KaFai Lau,
Hannes Frederic Sowa
Cc: netdev, Daniel Borkmann, kernel-team
In-Reply-To: <affe7228-edf1-5307-2c0c-3ddb0cf247ae@fb.com>
On 6/1/17 3:48 PM, Alexei Starovoitov wrote:
> You saw patch 7/8, right?
Apparently, not close enough. Nothing in the commit message mentioned
returning instructions. I skimmed the patch and filled in that GET_INFO
was returning just the meta-data.
^ permalink raw reply
* Re: [PATCH net-next] bpf, arm64: implement jiting of BPF_XADD
From: Will Deacon @ 2017-06-02 12:02 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, zlim.lnx, netdev, linux-arm-kernel, ast, peterz
In-Reply-To: <47ce6fc238596120f02fb6c7116f05b30be2f377.1493599299.git.daniel@iogearbox.net>
Hi Daniel,
[sorry, only just noticed that was queued]
On Mon, May 01, 2017 at 02:57:20AM +0200, Daniel Borkmann wrote:
> This work adds BPF_XADD for BPF_W/BPF_DW to the arm64 JIT and therefore
> completes JITing of all BPF instructions, meaning we can thus also remove
> the 'notyet' label and do not need to fall back to the interpreter when
> BPF_XADD is used in a program!
>
> This now also brings arm64 JIT in line with x86_64, s390x, ppc64, sparc64,
> where all current eBPF features are supported.
>
> BPF_W example from test_bpf:
>
> .u.insns_int = {
> BPF_ALU32_IMM(BPF_MOV, R0, 0x12),
> BPF_ST_MEM(BPF_W, R10, -40, 0x10),
> BPF_STX_XADD(BPF_W, R10, R0, -40),
> BPF_LDX_MEM(BPF_W, R0, R10, -40),
> BPF_EXIT_INSN(),
> },
>
> [...]
> 00000020: 52800247 mov w7, #0x12 // #18
> 00000024: 928004eb mov x11, #0xffffffffffffffd8 // #-40
> 00000028: d280020a mov x10, #0x10 // #16
> 0000002c: b82b6b2a str w10, [x25,x11]
> // start of xadd mapping:
> 00000030: 928004ea mov x10, #0xffffffffffffffd8 // #-40
> 00000034: 8b19014a add x10, x10, x25
> 00000038: f9800151 prfm pstl1strm, [x10]
> 0000003c: 885f7d4b ldxr w11, [x10]
> 00000040: 0b07016b add w11, w11, w7
> 00000044: 880b7d4b stxr w11, w11, [x10]
This form of STXR (where s == t) is CONSTRAINED UNPREDICTABLE per the
architecture; you need to use separate registers for the data and the
status flag. You might also be interested in the atomic instructions
introduced in ARMv8.1, which includes the LDADD instruction. You can
check elf_hwcap & HWCAP_ATOMICS to see if it's supported.
Also, did we get a conclusion on the barrier semantics for this? Currently
you don't have any here: is that ok?
Will
^ permalink raw reply
* Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
From: Yan, Zheng @ 2017-06-02 12:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Deepa Dinamani, John Stultz, Linux Kernel Mailing List,
Andrew Morton, Thomas Gleixner, Al Viro, gregkh, Dilger, Andreas,
J. Bruce Fields, Chris Mason, David Miller, David Sterba,
Evgeniy Dushistov, Eric Paris, Jaegeuk Kim, Josef Bacik,
Jeff Layton, James Simmons, Ingo Molnar, Drokin, Oleg
In-Reply-To: <CAK8P3a3m3nt6rfvAvDG6HFuUvy+qWbmk5K0UtLGqYhYHOfdF8w@mail.gmail.com>
On Fri, Jun 2, 2017 at 7:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jun 2, 2017 at 1:18 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 6:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>>>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>>>
>>>>> I believe the bug you see is the result of the two timestamps
>>>>> currently being almost guaranteed to be different in the latest
>>>>> kernels.
>>>>> Changing r_stamp to use current_kernel_time() will make it the
>>>>> same value most of the time (as it was before Deepa's patch),
>>>>> but when the timer interrupt happens between the timestamps,
>>>>> the two are still different, it's just much harder to hit.
>>>>>
>>>>> I think the proper solution should be to change __ceph_setattr()
>>>>> in a way that has req->r_stamp always synchronized with i_ctime.
>>>>> If we copy i_ctime to r_stamp, that will also take care of the
>>>>> future issues with the planned changes to current_time().
>>>>>
>>>> I already have a patch
>>>> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
>>>
>>> Looks good to me. In case anyone cares:
>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>
>>>>> The part I don't understand is what else r_stamp (i.e. the time
>>>>> stamp in ceph_msg_data with type==
>>>>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>>>>> ctime in CEPH_MDS_OP_SETATTR.
>>>>>
>>>>> Will this be used to update the stored i_ctime for other operations
>>>>> too? If so, we would need to synchronize it with the in-memory
>>>>> i_ctime for all operations that do this.
>>>>>
>>>>
>>>> yes, mds uses it to update ctime of modified inodes. For example,
>>>> when handling mkdir, mds set ctime of both parent inode and new inode
>>>> to r_stamp.
>>>
>>> I see, so we may have a variation of that problem there as well: From
>>> my reading of the code, the child inode is not in memory yet, so
>>> that seems fine, but I could not find where the parent in-memory inode
>>> i_ctime is updated in ceph, but it is most likely not the same as
>>> req->r_stamp (assuming it gets updated at all).
>>
>> i_ctime is updated when handling request reply, by ceph_fill_file_time().
>> __ceph_setattr() can update the in-memory inode's ctime after request
>> reply is received. The difference between ktime_get_real_ts() and
>> current_time() can be larger than round-trip time of request. So it's
>> still possible that __ceph_setattr() make ctime go back.
>
> But the __ceph_setattr() problem should be fixed by your patch, right?
>
> What I meant is another related problem in ceph_mkdir() where the
> i_ctime field of the parent inode is different between the persistent
> representation in the mds and the in-memory representation.
>
I don't see any problem in mkdir case. Parent inode's i_ctime in mds is set to
r_stamp. When client receives request reply, it set its in-memory inode's ctime
to the same time stamp.
Regards
Yan, Zheng
> Arnd
>
>>> Would it make sense require all callers of ceph_mdsc_do_request()
>>> to update r_stamp at the same time as i_ctime to keep them in sync?
^ permalink raw reply
* [PATCH v3 0/6] DT: Fix spelling of standard properties
From: Geert Uytterhoeven @ 2017-06-02 12:38 UTC (permalink / raw)
To: David Airlie, Rob Herring, Mark Rutland, Carlo Caione,
Kevin Hilman, Chanho Min, Catalin Marinas, Will Deacon
Cc: Neil Armstrong, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Geert Uytterhoeven
Hi all,
This patch series fixes misspellings of various standard DT properties
in DT binding documentation, DTS files, and examples.
While most of these are harmless, some of them may cause hard-to-debug
failures.
Changes compared to v3:
- Drop patches that have been applied already,
- Add Acked-by,
- Add new patches 5 and 6.
Changes compared to v2:
- Drop patches that have been applied already,
- Add Rob Herring's Acked-by,
- Split off "[PATCH v2 4/6] ASoC: davinci-mcbsp: DT fix
s/interrupts-names/interrupt-names/" from the unrelated "[PATCH 06/14]
dmaengine: bcm2835: DT spelling s/interrupts-names/interrupt-names/",
- Add new patch "[PATCH v2 3/6] arm64: dts: lg1313: DT fix
s/#interrupts-cells/#interrupt-cells/".
Please apply where appropriate.
Thanks!
P.S. I used the following to detect misspellings:
words="(address|clock|cooling|dma|gpio|index|interrupt|msi|nvmem|phy|phys|power-domain|pwm|reset|size|sleep|sound-dai|thermal-sensor)"
git grep -Ew "${words}s-names"
git grep -E "[^-]\<${words}-name\>[^-]"
git grep -Ew "#${words}s-cells" # false positive phys-cells
git grep -E "#${words}-cell\>[^-]"
git grep -w adress-cells
git grep -Ew "interrupts-(map|parent)"
Geert Uytterhoeven (6):
arm64: dts: lg1312: DT fix s/#interrupts-cells/#interrupt-cells/
arm64: dts: lg1313: DT fix s/#interrupts-cells/#interrupt-cells/
dt: booting-without-of: DT fix s/#interrupt-cell/#interrupt-cells/
powerpc: dts: acadia: DT fix s/#interrupts-parent/#interrupt-parent/
dt-bindings: display: amlogic: DT fix s/resets-names/reset-names/
dt-bindings: net: btusb: DT fix s/interrupt-name/interrupt-names/
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 2 +-
Documentation/devicetree/bindings/net/btusb.txt | 2 +-
Documentation/devicetree/booting-without-of.txt | 2 +-
arch/arm64/boot/dts/lg/lg1312.dtsi | 2 +-
arch/arm64/boot/dts/lg/lg1313.dtsi | 2 +-
arch/powerpc/boot/dts/acadia.dts | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v3 2/6] arm64: dts: lg1313: DT fix s/#interrupts-cells/#interrupt-cells/
From: Geert Uytterhoeven @ 2017-06-02 12:38 UTC (permalink / raw)
To: David Airlie, Rob Herring, Mark Rutland, Carlo Caione,
Kevin Hilman, Chanho Min, Catalin Marinas, Will Deacon
Cc: Neil Armstrong, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, dri-devel, linux-amlogic, devicetree,
linux-arm-kernel, linux-kernel, netdev, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <1496407129-13527-1-git-send-email-geert+renesas@glider.be>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Chanho Min <chanho.min@lge.com>
---
v3:
- Add Acked-by,
v2:
- New.
---
arch/arm64/boot/dts/lg/lg1313.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/lg/lg1313.dtsi b/arch/arm64/boot/dts/lg/lg1313.dtsi
index e703e1149c757082..abb2162228e82d39 100644
--- a/arch/arm64/boot/dts/lg/lg1313.dtsi
+++ b/arch/arm64/boot/dts/lg/lg1313.dtsi
@@ -123,7 +123,7 @@
amba {
#address-cells = <2>;
#size-cells = <1>;
- #interrupts-cells = <3>;
+ #interrupt-cells = <3>;
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 5/6] dt-bindings: display: amlogic: DT fix s/resets-names/reset-names/
From: Geert Uytterhoeven @ 2017-06-02 12:38 UTC (permalink / raw)
To: David Airlie, Rob Herring, Mark Rutland, Carlo Caione,
Kevin Hilman, Chanho Min, Catalin Marinas, Will Deacon
Cc: Neil Armstrong, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, dri-devel, linux-amlogic, devicetree,
linux-arm-kernel, linux-kernel, netdev, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <1496407129-13527-1-git-send-email-geert+renesas@glider.be>
Fixes: 8cceda5349377e30 ("dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3:
- New.
---
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
index 7f040edc16fe6325..a65c890e3170f875 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
@@ -43,7 +43,7 @@ Required properties:
and the Amlogic Meson venci clocks as described in
Documentation/devicetree/bindings/clock/clock-bindings.txt,
the clocks are soc specific, the clock-names should be "iahb", "isfr", "venci"
-- resets, resets-names: must have the phandles to the HDMI apb, glue and phy
+- resets, reset-names: must have the phandles to the HDMI apb, glue and phy
resets as described in :
Documentation/devicetree/bindings/reset/reset.txt,
the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
--
2.7.4
^ permalink raw reply related
* [PATCH v3 6/6] dt-bindings: net: btusb: DT fix s/interrupt-name/interrupt-names/
From: Geert Uytterhoeven @ 2017-06-02 12:38 UTC (permalink / raw)
To: David Airlie, Rob Herring, Mark Rutland, Carlo Caione,
Kevin Hilman, Chanho Min, Catalin Marinas, Will Deacon
Cc: Neil Armstrong, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, dri-devel, linux-amlogic, devicetree,
linux-arm-kernel, linux-kernel, netdev, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <1496407129-13527-1-git-send-email-geert+renesas@glider.be>
Fixes: fd913ef7ce619467 ("Bluetooth: btusb: Add out-of-band wakeup support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3:
- New.
---
Documentation/devicetree/bindings/net/btusb.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
index 01fa2d4188d4a900..18dd9c386be094db 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -37,7 +37,7 @@ Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
compatible = "usb1286,204e";
reg = <1>;
interrupt-parent = <&gpio0>;
- interrupt-name = "wakeup";
+ interrupt-names = "wakeup";
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/6] powerpc: dts: acadia: DT fix s/#interrupts-parent/#interrupt-parent/
From: Geert Uytterhoeven @ 2017-06-02 12:38 UTC (permalink / raw)
To: David Airlie, Rob Herring, Mark Rutland, Carlo Caione,
Kevin Hilman, Chanho Min, Catalin Marinas, Will Deacon
Cc: Neil Armstrong, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, dri-devel, linux-amlogic, devicetree,
linux-arm-kernel, linux-kernel, netdev, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <1496407129-13527-1-git-send-email-geert+renesas@glider.be>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
---
v3:
- No changes,
v2:
- Add Acked-by.
---
arch/powerpc/boot/dts/acadia.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/acadia.dts b/arch/powerpc/boot/dts/acadia.dts
index 57291f61ffe7021a..86266159521edac2 100644
--- a/arch/powerpc/boot/dts/acadia.dts
+++ b/arch/powerpc/boot/dts/acadia.dts
@@ -183,7 +183,7 @@
usb@ef603000 {
compatible = "ohci-be";
reg = <0xef603000 0x80>;
- interrupts-parent = <&UIC0>;
+ interrupt-parent = <&UIC0>;
interrupts = <0xd 0x4 0xe 0x4>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/6] arm64: dts: lg1312: DT fix s/#interrupts-cells/#interrupt-cells/
From: Geert Uytterhoeven @ 2017-06-02 12:38 UTC (permalink / raw)
To: David Airlie, Rob Herring, Mark Rutland, Carlo Caione,
Kevin Hilman, Chanho Min, Catalin Marinas, Will Deacon
Cc: Neil Armstrong, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, dri-devel, linux-amlogic, devicetree,
linux-arm-kernel, linux-kernel, netdev, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <1496407129-13527-1-git-send-email-geert+renesas@glider.be>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Chanho Min <chanho.min@lge.com>
---
v3:
- Add Acked-by,
v2:
- Add Acked-by,
- Rebased.
---
arch/arm64/boot/dts/lg/lg1312.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/lg/lg1312.dtsi b/arch/arm64/boot/dts/lg/lg1312.dtsi
index fbafa24cd5335b90..647606a83c517448 100644
--- a/arch/arm64/boot/dts/lg/lg1312.dtsi
+++ b/arch/arm64/boot/dts/lg/lg1312.dtsi
@@ -123,7 +123,7 @@
amba {
#address-cells = <2>;
#size-cells = <1>;
- #interrupts-cells = <3>;
+ #interrupt-cells = <3>;
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/6] dt: booting-without-of: DT fix s/#interrupt-cell/#interrupt-cells/
From: Geert Uytterhoeven @ 2017-06-02 12:38 UTC (permalink / raw)
To: David Airlie, Rob Herring, Mark Rutland, Carlo Caione,
Kevin Hilman, Chanho Min, Catalin Marinas, Will Deacon
Cc: Neil Armstrong, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, dri-devel, linux-amlogic, devicetree,
linux-arm-kernel, linux-kernel, netdev, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <1496407129-13527-1-git-send-email-geert+renesas@glider.be>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
---
v3:
- No changes,
v2:
- Add Acked-by.
---
Documentation/devicetree/booting-without-of.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index 280d283304bb82d8..f35d3adacb987f7d 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -1309,7 +1309,7 @@ number and level/sense information. All interrupt children in an
OpenPIC interrupt domain use 2 cells per interrupt in their interrupts
property.
-The PCI bus binding specifies a #interrupt-cell value of 1 to encode
+The PCI bus binding specifies a #interrupt-cells value of 1 to encode
which interrupt pin (INTA,INTB,INTC,INTD) is used.
2) interrupt-parent property
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/5] net: phy: add 802.3 clause 45 support to phylib
From: Russell King - ARM Linux @ 2017-06-02 12:39 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev
In-Reply-To: <34431c1b-025f-55e5-9f31-34e14493541b@gmail.com>
On Thu, Jun 01, 2017 at 10:15:28AM -0700, Florian Fainelli wrote:
> On 06/01/2017 03:26 AM, Russell King wrote:
> > Add generic helpers for 802.3 clause 45 PHYs for >= 10Gbps support.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
>
> > + ctrl1 &= ~MDIO_CTRL1_SPEEDSEL;
> > + /* PMA/PMD type selection is 1.7.5:0 not 1.7.3:0. See 45.2.1.6.1. */
> > + ctrl2 &= ~(MDIO_PMA_CTRL2_TYPE | 0x30);
>
> You could add a define for this 0x30 to indicate that you are masking
> off the reserved bits (there are more entries that are reserved
> actually, but that would do for now).
They are not reserved according to 802.3-2015 and 802.3-2012:
802.3-2012: 45.2.1.6.1 PMA/PMD type selection (1.7.5:0)
802.3-2015: 45.2.1.6.3 PMA/PMD type selection (1.7.5:0)
which defines the type selection as occupying six bits, but the definition
in the UAPI mdio.h header file is:
#define MDIO_PMA_CTRL2_TYPE 0x000f /* PMA/PMD type selection */
I presume that this is according to an earlier version of 802.3.
Changing this definition may cause userspace and/or kernel regressions,
so I propose something like:
#define MDIO_PMA_CTRL2_TYPE_2012 0x003f /* PMA/PMD type selection */
instead. The rest of the reserved entries are not specified as being
part of the type selection (yet) so it would be inappropriate to change
their value.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 2/5] net: phy: hook up clause 45 autonegotiation restart
From: Russell King - ARM Linux @ 2017-06-02 12:43 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev
In-Reply-To: <23c238e0-2af8-3171-9986-af02e9c19129@gmail.com>
On Thu, Jun 01, 2017 at 10:16:17AM -0700, Florian Fainelli wrote:
> On 06/01/2017 09:24 AM, Russell King - ARM Linux wrote:
> > Checking 802.3-2015, in "22.2.4 Management functions", the first
> > sentence requires all PHYs that respond to Clause 22 cycles to
> > implement BMCR and BMSR. However, my statement about unimplemented
> > registers returning zero seems to be a C45 thing, not a C22 thing,
> > according to the C22 PICS and "45.2 MDIO Interface Registers"
> >
> > However, digging a bit further, "22.2.4.2.10 Auto-Negotiation complete"
> > states that bit 5 shall be zero if aneg has not completed or if aneg is
> > unimplemented.
> >
>
> So how about we are more defensive than that and if we are presented
> with a C45 PHY driver that does not have an aneg_done() function pointer
> set we return an error/warning during driver registration?
We don't mark drivers as being C22 or C45, we rely on them matching
the IDs and/or the probe function making that decision, so it's a
tad difficult to make that decision at driver registration time.
We could reject an attempt to probe a C45 phy with a driver that
does not provide an aneg_done() pointer.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH] virtio_net: lower limit on buffer size
From: Mikulas Patocka @ 2017-06-02 13:16 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, J. Bruce Fields, Jason Wang, virtualization, netdev
In-Reply-To: <1496361148-4603-1-git-send-email-mst@redhat.com>
On Fri, 2 Jun 2017, Michael S. Tsirkin wrote:
> commit d85b758f72b0 "virtio_net: fix support for small rings"
> was supposed to increase the buffer size for small rings
> but had an unintentional side effect of decreasing
> it for large rings. This seems to break some setups -
> it's not yet clear why, but increasing buffer size
> back to what it was before helps.
>
> Fixes: d85b758f72b0 "virtio_net: fix support for small rings"
> Reported-by: Mikulas Patocka <mpatocka@redhat.com>
> Reported-by: "J. Bruce Fields" <bfields@fieldses.org>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Can reporters please confirm whether the following helps?
> If it does I think we should queue it even though I expect I'll need to
> investigate the exact reasons for the failure down the road - probably
> a hypervisor bug.
Hi
This patch fixes the problem for me.
Mikulas
> drivers/net/virtio_net.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 87b5c20..60abb5d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -842,7 +842,7 @@ static unsigned int get_mergeable_buf_len(struct receive_queue *rq,
> unsigned int len;
>
> len = hdr_len + clamp_t(unsigned int, ewma_pkt_len_read(avg_pkt_len),
> - rq->min_buf_len - hdr_len, PAGE_SIZE - hdr_len);
> + rq->min_buf_len, PAGE_SIZE - hdr_len);
> return ALIGN(len, L1_CACHE_BYTES);
> }
>
> @@ -2039,7 +2039,8 @@ static unsigned int mergeable_min_buf_len(struct virtnet_info *vi, struct virtqu
> unsigned int buf_len = hdr_len + ETH_HLEN + VLAN_HLEN + packet_len;
> unsigned int min_buf_len = DIV_ROUND_UP(buf_len, rq_size);
>
> - return max(min_buf_len, hdr_len);
> + return max(max(min_buf_len, hdr_len) - hdr_len,
> + (unsigned int)GOOD_PACKET_LEN);
> }
>
> static int virtnet_find_vqs(struct virtnet_info *vi)
> --
> MST
>
^ permalink raw reply
* Re: [PATCH 2/5] net: phy: hook up clause 45 autonegotiation restart
From: Andrew Lunn @ 2017-06-02 13:46 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: Florian Fainelli, netdev
In-Reply-To: <20170602124339.GO22219@n2100.armlinux.org.uk>
On Fri, Jun 02, 2017 at 01:43:39PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 01, 2017 at 10:16:17AM -0700, Florian Fainelli wrote:
> > On 06/01/2017 09:24 AM, Russell King - ARM Linux wrote:
> > > Checking 802.3-2015, in "22.2.4 Management functions", the first
> > > sentence requires all PHYs that respond to Clause 22 cycles to
> > > implement BMCR and BMSR. However, my statement about unimplemented
> > > registers returning zero seems to be a C45 thing, not a C22 thing,
> > > according to the C22 PICS and "45.2 MDIO Interface Registers"
> > >
> > > However, digging a bit further, "22.2.4.2.10 Auto-Negotiation complete"
> > > states that bit 5 shall be zero if aneg has not completed or if aneg is
> > > unimplemented.
> > >
> >
> > So how about we are more defensive than that and if we are presented
> > with a C45 PHY driver that does not have an aneg_done() function pointer
> > set we return an error/warning during driver registration?
>
> We don't mark drivers as being C22 or C45, we rely on them matching
> the IDs and/or the probe function making that decision, so it's a
> tad difficult to make that decision at driver registration time.
>
> We could reject an attempt to probe a C45 phy with a driver that
> does not provide an aneg_done() pointer.
Just an idea.
We could make phy_read/phy_write look to see if the is_c45 flag is
set. If so, return -EINVAL if the register being accessed does not
have MII_ADDR_C45.
That should catch all these sort of problems.
Andrew
^ permalink raw reply
* pull-request: mac80211 2017-06-02
From: Johannes Berg @ 2017-06-02 13:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here I just have two fixes for issues that folks reported to me recently.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 029c58178b9aa0a293a86ee0da3355611ac99d07:
Merge tag 'mac80211-for-davem-2017-05-23' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2017-05-24 15:31:39 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-06-02
for you to fetch changes up to e165bc02a02c70e40d5c811c705ba269aeca0497:
mac80211: fix dropped counter in multiqueue RX (2017-06-01 21:26:03 +0200)
----------------------------------------------------------------
Just two fixes:
* fix the per-CPU drop counters to not be added to the
rx_packets counter, but really the drop counter
* fix TX aggregation start/stop callback races by setting
bits instead of allocating and queueing an skb
----------------------------------------------------------------
Johannes Berg (2):
mac80211: fix TX aggregation start/stop callback race
mac80211: fix dropped counter in multiqueue RX
net/mac80211/agg-tx.c | 128 ++++++++++++++++++---------------------------
net/mac80211/ht.c | 16 ++++--
net/mac80211/ieee80211_i.h | 14 ++---
net/mac80211/iface.c | 11 +---
net/mac80211/sta_info.c | 2 +-
net/mac80211/sta_info.h | 2 +
6 files changed, 72 insertions(+), 101 deletions(-)
^ permalink raw reply
* [PATCH net 1/1] qlcnic: Fix tunnel offload for 82xx adapters
From: Manish Chopra @ 2017-06-02 13:52 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-GELinuxNICDev
Qlogic's 82xx series adapter doesn't support
tunnel offloads, driver incorrectly assumes that it is
supported and causes firmware hang while running tunnel IO.
This patch fixes this by not advertising tunnel offloads
for 82xx adapters.
Signed-off-by: Manish Chopra <manish.chopra@cavium.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 26 ++++++++++++++++++++--
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 2 ++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 2 ++
.../ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 2 ++
4 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 7245b10..8131292 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -1824,22 +1824,44 @@ struct qlcnic_hardware_ops {
u32 (*get_cap_size)(void *, int);
void (*set_sys_info)(void *, int, u32);
void (*store_cap_mask)(void *, u32);
+ bool (*encap_rx_offload) (struct qlcnic_adapter *adapter);
+ bool (*encap_tx_offload) (struct qlcnic_adapter *adapter);
};
extern struct qlcnic_nic_template qlcnic_vf_ops;
-static inline bool qlcnic_encap_tx_offload(struct qlcnic_adapter *adapter)
+static inline bool qlcnic_83xx_encap_tx_offload(struct qlcnic_adapter *adapter)
{
return adapter->ahw->extra_capability[0] &
QLCNIC_83XX_FW_CAPAB_ENCAP_TX_OFFLOAD;
}
-static inline bool qlcnic_encap_rx_offload(struct qlcnic_adapter *adapter)
+static inline bool qlcnic_83xx_encap_rx_offload(struct qlcnic_adapter *adapter)
{
return adapter->ahw->extra_capability[0] &
QLCNIC_83XX_FW_CAPAB_ENCAP_RX_OFFLOAD;
}
+static inline bool qlcnic_82xx_encap_tx_offload(struct qlcnic_adapter *adapter)
+{
+ return false;
+}
+
+static inline bool qlcnic_82xx_encap_rx_offload(struct qlcnic_adapter *adapter)
+{
+ return false;
+}
+
+static inline bool qlcnic_encap_rx_offload(struct qlcnic_adapter *adapter)
+{
+ return adapter->ahw->hw_ops->encap_rx_offload(adapter);
+}
+
+static inline bool qlcnic_encap_tx_offload(struct qlcnic_adapter *adapter)
+{
+ return adapter->ahw->hw_ops->encap_tx_offload(adapter);
+}
+
static inline int qlcnic_start_firmware(struct qlcnic_adapter *adapter)
{
return adapter->nic_ops->start_firmware(adapter);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
index 4fb6879..f7080d0 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
@@ -242,6 +242,8 @@ static struct qlcnic_hardware_ops qlcnic_83xx_hw_ops = {
.get_cap_size = qlcnic_83xx_get_cap_size,
.set_sys_info = qlcnic_83xx_set_sys_info,
.store_cap_mask = qlcnic_83xx_store_cap_mask,
+ .encap_rx_offload = qlcnic_83xx_encap_rx_offload,
+ .encap_tx_offload = qlcnic_83xx_encap_tx_offload,
};
static struct qlcnic_nic_template qlcnic_83xx_ops = {
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index b6628aa..1b5f7d5 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -632,6 +632,8 @@ static struct qlcnic_hardware_ops qlcnic_hw_ops = {
.get_cap_size = qlcnic_82xx_get_cap_size,
.set_sys_info = qlcnic_82xx_set_sys_info,
.store_cap_mask = qlcnic_82xx_store_cap_mask,
+ .encap_rx_offload = qlcnic_82xx_encap_rx_offload,
+ .encap_tx_offload = qlcnic_82xx_encap_tx_offload,
};
static int qlcnic_check_multi_tx_capability(struct qlcnic_adapter *adapter)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
index 2f656f3..c58180f 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
@@ -77,6 +77,8 @@ static struct qlcnic_hardware_ops qlcnic_sriov_vf_hw_ops = {
.free_mac_list = qlcnic_sriov_vf_free_mac_list,
.enable_sds_intr = qlcnic_83xx_enable_sds_intr,
.disable_sds_intr = qlcnic_83xx_disable_sds_intr,
+ .encap_rx_offload = qlcnic_83xx_encap_rx_offload,
+ .encap_tx_offload = qlcnic_83xx_encap_tx_offload,
};
static struct qlcnic_nic_template qlcnic_sriov_vf_ops = {
--
2.7.2
^ permalink raw reply related
* Re: [PATCH net] net: dsa: Move dsa_switch_{suspend,resume} out of legacy.c
From: Andrew Lunn @ 2017-06-02 13:53 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Vivien Didelot, David S. Miller, open list
In-Reply-To: <20170602025304.14298-1-f.fainelli@gmail.com>
On Thu, Jun 01, 2017 at 07:53:04PM -0700, Florian Fainelli wrote:
> dsa_switch_suspend() and dsa_switch_resume() are functions that belong in
> net/dsa/dsa.c and are not part of the legacy platform support code.
>
> Fixes: a6a71f19fe5e ("net: dsa: isolate legacy code")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: make two functions static
From: Andrew Lunn @ 2017-06-02 14:00 UTC (permalink / raw)
To: Colin King; +Cc: Florian Fainelli, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170602111424.31287-1-colin.king@canonical.com>
On Fri, Jun 02, 2017 at 12:14:24PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> functions m88e1510_get_temp_critical and m88e1510_get_temp_alarm can be
> made static as they not need to be in global scope.
>
> Cleans up sparse warnings:
> "symbol 'm88e1510_get_temp_alarm' was not declared. Should it be static?"
> "symbol 'm88e1510_get_temp_critical' was not declared. Should it be
> static?"
Hi Colin
What about m88e1510_get_temp_alarm()? That should also have a static.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: make two functions static
From: Colin Ian King @ 2017-06-02 14:04 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170602140014.GK12261@lunn.ch>
On 02/06/17 15:00, Andrew Lunn wrote:
> On Fri, Jun 02, 2017 at 12:14:24PM +0100, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> functions m88e1510_get_temp_critical and m88e1510_get_temp_alarm can be
>> made static as they not need to be in global scope.
>>
>> Cleans up sparse warnings:
>> "symbol 'm88e1510_get_temp_alarm' was not declared. Should it be static?"
>> "symbol 'm88e1510_get_temp_critical' was not declared. Should it be
>> static?"
>
> Hi Colin
>
> What about m88e1510_get_temp_alarm()? That should also have a static.
Ah, good point, I somehow missed that one. I'll send a V2
Colin
>
> Thanks
> Andrew
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/5] net: phy: hook up clause 45 autonegotiation restart
From: Russell King - ARM Linux @ 2017-06-02 14:04 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev
In-Reply-To: <20170602134632.GI12261@lunn.ch>
On Fri, Jun 02, 2017 at 03:46:32PM +0200, Andrew Lunn wrote:
> On Fri, Jun 02, 2017 at 01:43:39PM +0100, Russell King - ARM Linux wrote:
> > We don't mark drivers as being C22 or C45, we rely on them matching
> > the IDs and/or the probe function making that decision, so it's a
> > tad difficult to make that decision at driver registration time.
> >
> > We could reject an attempt to probe a C45 phy with a driver that
> > does not provide an aneg_done() pointer.
>
> Just an idea.
>
> We could make phy_read/phy_write look to see if the is_c45 flag is
> set. If so, return -EINVAL if the register being accessed does not
> have MII_ADDR_C45.
>
> That should catch all these sort of problems.
I'm not so sure we want to do that. Clause 45 PHYs are allowed to
respond to Clause 22 accesses, and MMD 29 contain a set of Clause 22
extension registers.
It seems it's possible for a PHY to support Clause 22 accesses along
with Clause 45 and MMD29 to extend the features beyond those supported
by the Clause 22 definition without providing the other MMDs.
Note that the Clause 45 definitions omit the 1000baseT registers
(MII_CTRL1000 / MII_STAT1000, or even registers that give the equivalent
information) from the 802.3 definition - this is why I've ended up
having to use the Marvell vendor specific 0xa016 register to determine
the PHY operating mode. So, a conventional 10/100/1G PHY but with C45
support would still want to access C22 registers.
Hence, I don't think we can block C22 accesses in the way you're
suggesting.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ 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