Quoting Landen Chao :
On Wed, 2020-08-19 at 00:09 +0800, Andrew Lunn wrote:
On Tue, Aug 18, 2020 at 03:14:10PM +0800, Landen Chao wrote:
> Add new support for MT7531:
>
> MT7531 is the next generation of MT7530. It is also a 7-ports switch with
> 5 giga embedded phys, 2 cpu ports, and the same
From: Chuck Lever
[ Upstream commit 64d26422516b2e347b32e6d9b1d40b3c19a62aae ]
During a connection tear down, the Receive queue is flushed before
the device resources are freed. Typically, all the Receives flush
with IB_WR_FLUSH_ERR.
However, any pending successful Receives flush with IB_WR_SUC
From: Chuck Lever
[ Upstream commit 64d26422516b2e347b32e6d9b1d40b3c19a62aae ]
During a connection tear down, the Receive queue is flushed before
the device resources are freed. Typically, all the Receives flush
with IB_WR_FLUSH_ERR.
However, any pending successful Receives flush with IB_WR_SUC
From: Chuck Lever
[ Upstream commit 64d26422516b2e347b32e6d9b1d40b3c19a62aae ]
During a connection tear down, the Receive queue is flushed before
the device resources are freed. Typically, all the Receives flush
with IB_WR_FLUSH_ERR.
However, any pending successful Receives flush with IB_WR_SUC
For bpf_map_elem and bpf_sk_local_storage bpf iterators,
additional map_id should be shown for fdinfo and
userspace query. For example, the following is for
a bpf_map_elem iterator.
$ cat /proc/1753/fdinfo/9
pos:0
flags: 0200
mnt_id: 14
link_type: iter
link_id:34
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter
From: Chuck Lever
[ Upstream commit 64d26422516b2e347b32e6d9b1d40b3c19a62aae ]
During a connection tear down, the Receive queue is flushed before
the device resources are freed. Typically, all the Receives flush
with IB_WR_FLUSH_ERR.
However, any pending successful Receives flush with IB_WR_SUC
This patch implemented bpf_link callback functions
show_fdinfo and fill_link_info to support link_query
interface.
The general interface for show_fdinfo and fill_link_info
will print/fill the target_name. Each targets can
register show_fdinfo and fill_link_info callbacks
to print/fill more target
"link" has been an important concept for bpf ecosystem to connect
bpf program with other properties. Currently, the information related
information can be queried from userspace through bpf command
BPF_LINK_GET_NEXT_ID, BPF_LINK_GET_FD_BY_ID and BPF_OBJ_GET_INFO_BY_FD.
The information is also avail
On 8/19/2020 4:36 PM, David Miller wrote:
> From: Jacob Keller
> Date: Tue, 18 Aug 2020 17:28:15 -0700
>
>> @@ -991,6 +993,12 @@ enum devlink_trap_group_generic_id {
>> }
>>
>> struct devlink_ops {
>> +/**
>> + * @supported_flash_update_params:
>> + * mask of parameters sup
From: Tonghao Zhang
Date: Thu, 20 Aug 2020 07:21:33 +0800
> On Thu, Aug 20, 2020 at 6:52 AM David Miller wrote:
>
>> From: xiangxia.m@gmail.com
>>
>> Date: Tue, 18 Aug 2020 18:09:22 +0800
>>
>>
>>
>> > Decrease table->count and ufid_count unconditionally,
>>
>>
>>
>> You don't explain why t
On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote:
>
> On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> wrote:
> > So, IMO, the best is to keep it on staging for a while, until those
> > remaining bugs gets solved.
> >
> > I added this series, together with the regulator driver and
> > a f
On 2020/8/19 1:04, Andrew Lunn wrote:
> On Tue, Aug 18, 2020 at 11:15:00PM +0800, YueHaibing wrote:
>> The "plat->phy_interface" variable is an enum and in this context GCC
>> will treat it as an unsigned int so the error handling is never
>> triggered.
>>
>> Fixes: b9f0b2f634c0 ("net: stmmac: plat
On Sun, Aug 16, 2020 at 6:48 PM Sedat Dilek wrote:
>
> On Sun, Aug 16, 2020 at 5:01 PM Willy Tarreau wrote:
> >
> > Hi,
> >
> > so as I mentioned, I could run several test on our lab with variations
> > around the various proposals and come to quite positive conclusions.
> >
> > Synthetic observa
On 8/19/20 7:27 PM, Fāng-ruì Sòng wrote:
section(36) .comment, size 44, link 0, flags 30, type=1
section(37) .debug_aranges, size 45684, link 0, flags 800, type=1
- fixing wrong alignment sh_addralign 16, expected 8
section(38) .debug_info, size 129104957, link 0, flags 800, t
On Wed, Aug 19, 2020 at 7:01 PM John Stultz wrote:
>
> On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote:
> >
> > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> > wrote:
> > > So, IMO, the best is to keep it on staging for a while, until those
> > > remaining bugs gets solved.
> > >
> >
On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> We have the same defines for K0 and K1 in include/linux/prandom.h and
> lib/random32.c?
> More room for simplifications?
Definitely, I'm not surprized at all. As I said, the purpose was to
discuss around the proposal, not much more. If
On Wed, Aug 19, 2020 at 12:07:09PM -0700, David Miller wrote:
> Yes this fixes the problem, but it doesn't in any way deal with the
> callers who are doing this stuff.
>
> They are all likely using sendpage because they expect that it will
> avoid the copy, for performance reasons or whatever.
>
On Thu, Aug 20, 2020 at 6:33 AM Willy Tarreau wrote:
>
> On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> > We have the same defines for K0 and K1 in include/linux/prandom.h and
> > lib/random32.c?
> > More room for simplifications?
>
> Definitely, I'm not surprized at all. As I said
On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote:
> > > Could you explain what makes you think it's unused? It's a feature of
> > > the UAPI generally supported by the videobuf2 framework and relied on
> > > by Chromium OS to get any kind of reasonable performance when
> > > accessing V4
On Wed, Aug 19, 2020 at 04:11:52PM +0200, Tomasz Figa wrote:
> > > By the way, as a videobuf2 reviewer, I'd appreciate being CC'd on any
> > > series related to the subsystem-facing DMA API changes, since
> > > videobuf2 is one of the biggest users of it.
> >
> > The cc list is too long - I cc list
On Wed, Aug 19, 2020 at 04:22:29PM +0200, Tomasz Figa wrote:
> > > FWIW, I asked back in time what the plan is for non-coherent
> > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and
> > > dma_sync_*() was supposed to be the right thing to go with. [2] The
> > > same thread also explains
On Wed, Aug 19, 2020 at 03:07:04PM +0100, Robin Murphy wrote:
>> FWIW, I asked back in time what the plan is for non-coherent
>> allocations and it seemed like DMA_ATTR_NON_CONSISTENT and
>> dma_sync_*() was supposed to be the right thing to go with. [2] The
>> same thread also explains why dma_all
On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote:
> >
> > -Warning: These pieces of the DMA API should not be used in the
> > -majority of cases, since they cater for unlikely corner cases that
> > -don't belong in usual drivers.
> > +These APIs allow to allocate pages that can be used l
On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote:
> > > > Could you explain what makes you think it's unused? It's a feature of
> > > > the UAPI generally supported by the videobuf2 framework and relied on
> > > > by Ch
7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in
net_device")
inadvertently changed which XDP mode is assumed when no mode flags are
specified explicitly. Previously, driver mode was preferred, if driver
supported it. If not, generic SKB mode was chosen. That commit changed d
Hello,
syzbot found the following issue on:
HEAD commit:4993e4fe Add linux-next specific files for 20200814
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1181e1a690
kernel config: https://syzkaller.appspot.com/x/.config?x=2055bd0d83d5ee16
dashboard
ajay.kat...@microchip.com写道：
> Thanks for submitting the patch. The code changes looks okay to me.
>
> The driver is now moved out of staging so 'staging' prefix is not
> required in subject. For future patches on wilc driver, the 'staging'
> prefix can be removed.
>
> For this patch, I am not
When devm_clk_get() returns -EPROBE_DEFER, sdio_priv
should be freed just like when wilc_cfg80211_init()
fails.
Fixes: 8692b047e86cf ("staging: wilc1000: look for rtc_clk clock")
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Remove 'staging' prefix in subject.
---
drivers/net/wireless/microc
Add XDP support to the IGB driver.
The implementation follows the IXGBE XDP implementation
closely and I used the following patches as basis:
1. commit 924708081629 ("ixgbe: add XDP support for pass and drop actions")
2. commit 33fdc82f0883 ("ixgbe: add support for XDP_TX action")
3. commit ed93a3
When devm_clk_get() returns -EPROBE_DEFER, spi_priv
should be freed just like when wilc_cfg80211_init()
fails.
Fixes: 854d66df74aed ("staging: wilc1000: look for rtc_clk clock in spi mode")
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Remove 'staging' prefix in subject.
---
drivers/net/wire
Documentation/devicetree/bindings/net/dsa/dsa.txt says that the phy-mode
property should be specified on port nodes. However, the microchip
drivers read it from the switch node.
Let the driver use the per-port property and fall back to the old
location with a warning.
Fix in-tree users.
Signed-o
On Fri, Aug 07, 2020 at 09:47:20AM -0700, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:5a30a789 Merge tag 'x86-urgent-2020-08-02' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1660c85890
kernel config: http
On Thu, Aug 20, 2020 at 06:42:23AM +0200, Sedat Dilek wrote:
> On Thu, Aug 20, 2020 at 6:33 AM Willy Tarreau wrote:
> >
> > On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> > > We have the same defines for K0 and K1 in include/linux/prandom.h and
> > > lib/random32.c?
> > > More room
Record which built-ins are optional and needed for some of recent BPF CO-RE
subtests. Document Clang diff that fixed corner-case issue with
__builtin_btf_type_id().
Suggested-by: Alexei Starovoitov
Signed-off-by: Andrii Nakryiko
---
tools/testing/selftests/bpf/README.rst| 21 +++
GCC 4.9 seems to be more strict in some regards. Fix two minor issue it
reported.
Fixes: 1c1052e0140a ("tools/testing/selftests/bpf: Add self-tests for new
helper bpf_get_ns_current_pid_tgid.")
Fixes: 2d7824ffd25c ("selftests: bpf: Add test for sk_assign")
Signed-off-by: Andrii Nakryiko
---
too
BPF_CALL | BPF_JMP32 is explicitly not allowed by verifier for BPF helper
calls, so don't detect it as a valid call. Also drop the check on func_id
pointer, as it's currently always non-null.
Reported-by: Yonghong Song
Fixes: 109cea5a594f ("libbpf: Sanitize BPF program code for
bpf_probe_read_{k
GCC compilers older than version 5 don't support __builtin_mul_overflow yet.
Given GCC 4.9 is the minimal supported compiler for building kernel and the
fact that libbpf is a dependency of resolve_btfids, which is dependency of
CONFIG_DEBUG_INFO_BTF=y, this needs to be handled. This patch fixes the
Em Wed, 19 Aug 2020 14:13:05 -0700
John Stultz escreveu:
> On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> wrote:
> > Yet, I'm submitting it via staging due to the following reasons:
> >
> > - It depends on the LDO3 power supply, which is provided by
> > a regulator driver that it is c
On Thu, Aug 6, 2020 at 1:24 PM Alan Maguire wrote:
>
> A helper is added to support tracing kernel type information in BPF
> using the BPF Type Format (BTF). Its signature is
>
> long bpf_trace_btf(struct btf_ptr *ptr, u32 btf_ptr_size, u32 trace_id,
>u64 flags);
>
> struct bt
Hi David,
On Wed, Aug 19, 2020 at 10:05 PM David Miller wrote:
> From: Geert Uytterhoeven
> Date: Wed, 19 Aug 2020 14:45:39 +0200
>
> > - Remove pinctrl consumer properties, as they are handled by core
> > dt-schema,
> > - Document missing properties,
> > - Document missing PHY child n
Em Wed, 19 Aug 2020 23:25:51 +0200
Sam Ravnborg escreveu:
> Hi John.
>
> > > So, IMO, the best is to keep it on staging for a while, until those
> > > remaining bugs gets solved.
> >
> > I'm not sure I see all of these as compelling for pushing it in via
> > staging. And I suspect in the proc
There are a couple of spelling mistakes in comment text. Fix these.
Signed-off-by: Kaige Li
---
drivers/net/phy/mscc/mscc_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mscc/mscc_main.c b/drivers/net/phy/mscc/mscc_main.c
index a4fbf3a..6bc7406 1006
With disabling bh in the whole sctp_get_port_local(), when
snum == 0 and too many ports have been used, the do-while
loop will take the cpu for a long time and cause cpu stuck:
[ ] watchdog: BUG: soft lockup - CPU#11 stuck for 22s!
[ ] RIP: 0010:native_queued_spin_lock_slowpath+0x4de/0x940
[
On Thu, Aug 20, 2020 at 08:08:43AM +0200, Willy Tarreau wrote:
> On Thu, Aug 20, 2020 at 06:42:23AM +0200, Sedat Dilek wrote:
> > On Thu, Aug 20, 2020 at 6:33 AM Willy Tarreau wrote:
> > >
> > > On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> > > > We have the same defines for K0 an
301 - 345 of 345 matches
Mail list logo
