On 5/10/19 6:53 PM, Jay Vosburgh wrote:
Jarod Wilson wrote:
There's currently a problem with toggling arp_validate on and off with an
active-backup bond. At the moment, you can start up a bond, like so:
modprobe bonding mode=1 arp_interval=100 arp_validate=0
arp_ip_targets=192.168.1.1
ip lin
When adding missing callbacks I missed that one had them set already.
Interesting that the compiler didn't complain.
Fixes: daf3ddbe11a2 ("net: phy: realtek: add missing page operations")
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/realtek.c | 2 --
1 file changed, 2 deletions(-)
diff --
--
Hi
COSTCO WHOLESALE UK LIMITED are looking to buy your products and partner
with your company, can you please send us your Catalog or your website
to learn more about your products or prices list by email and if we can
make some order with you and start a long-term partnership. Can your
On Fri, May 10, 2019 at 08:52:49PM -0600, Shuah Khan wrote:
> commit 8ce72dc32578 ("selftests: fix headers_install circular dependency")
> broke bpf build/test workflow. When KBUILD_OUTPUT is set, bpf objects end
> up in KBUILD_OUTPUT build directory instead of in ../selftests/bpf.
>
> The followi
> From: Sunil Muthuswamy
> Sent: Wednesday, May 8, 2019 4:11 PM
>
> Currently, when a hvsock socket is closed, the socket is shutdown and
> immediately a RST is sent. There is no wait for the FIN packet to arrive
> from the other end. This can lead to data loss since the connection is
> terminated
On 5/9/19 8:17 PM, Alexei Starovoitov wrote:
On Thu, May 09, 2019 at 07:42:09PM -0600, Shuah Khan wrote:
On 5/9/19 4:40 PM, Shuah Khan wrote:
On 5/9/19 4:20 PM, Alexei Starovoitov wrote:
On Mon, May 06, 2019 at 10:56:56AM -0600, Shuah Khan wrote:
Hi Linus,
Please pull the following Kselftest
commit 8ce72dc32578 ("selftests: fix headers_install circular dependency")
broke bpf build/test workflow. When KBUILD_OUTPUT is set, bpf objects end
up in KBUILD_OUTPUT build directory instead of in ../selftests/bpf.
The following bpf workflow breaks when it can't find the test_verifier:
cd tools
On Fri, May 10, 2019 at 6:03 PM Daniel Borkmann wrote:
>
> systemtap folks reported the following splat recently:
...
> Note that unprivileged case is not affected from this.
>
> Fixes: 52875a04f4b2 ("bpf: verifier: remove dead code")
> Fixes: 2cbd95a5c4fb ("bpf: change parameters of call/branch o
about not implemented system calls)
Patch is against 5.1 (localversion-next is next-20190510)
net/qrtr/qrtr.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index dd0e97f..801872a 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
systemtap folks reported the following splat recently:
[ 7790.862212] WARNING: CPU: 3 PID: 26759 at
arch/x86/kernel/kprobes/core.c:1022 kprobe_fault_handler+0xec/0xf0
[...]
[ 7790.864113] CPU: 3 PID: 26759 Comm: sshd Not tainted
5.1.0-0.rc7.git1.1.fc31.x86_64 #1
[ 7790.864198] Hardware n
Add a couple of tests to make sure branch offset adjustments are
correctly performed.
Signed-off-by: Daniel Borkmann
---
tools/testing/selftests/bpf/verifier/jump.c | 151
1 file changed, 151 insertions(+)
diff --git a/tools/testing/selftests/bpf/verifier/jump.c
b/tools/te
On Fri, May 10, 2019 at 01:28:00PM -0700, David Miller wrote:
> From: Nicholas Mc Guire
> Date: Fri, 10 May 2019 03:08:53 +0200
>
> > diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
> > index dd0e97f..c90edaa 100644
> > --- a/net/qrtr/qrtr.c
> > +++ b/net/qrtr/qrtr.c
> > @@ -733,7 +733,8 @@ static
From: Yuchung Cheng
Date: Fri, 10 May 2019 16:00:19 -0700
> Fixes: 3844718c20d0 ("tcp: properly track retry time on passive Fast Open")
This is not a valid commit ID.
Jakub Kicinski wrote:
> On Thu, 09 May 2019 21:57:49 -0700, John Fastabend wrote:
> > @@ -2042,12 +2060,14 @@ void tls_sw_free_resources_tx(struct sock *sk)
> > if (atomic_read(&ctx->encrypt_pending))
> > crypto_wait_req(-EINPROGRESS, &ctx->async_wait);
> >
> > - release_sock(sk
Jarod Wilson wrote:
>There's currently a problem with toggling arp_validate on and off with an
>active-backup bond. At the moment, you can start up a bond, like so:
>
>modprobe bonding mode=1 arp_interval=100 arp_validate=0
>arp_ip_targets=192.168.1.1
>ip link set bond0 down
>echo "ens4f0" > /sy
Commit 3844718c20d0 ("tcp: properly track retry time on
passive Fast Open") sets the start of SYNACK retransmission
time on passive Fast Open in "retrans_stamp". However the
timestamp is not reset upon the handshake has completed. As a
result, future data packet retransmission may not update it in
From: Thomas Falcon
Date: Thu, 9 May 2019 23:13:43 -0500
> It was discovered in testing that the underlying hardware MAC
> address will revert to initial settings following a device reset,
> but the driver fails to resend the current OS MAC settings. This
> oversight can result in dropped packet
From: Wenbin Zeng
Date: Fri, 10 May 2019 14:36:02 +0800
> The newly added netns_evict() shall be called when the netns inode being
> evicted. It provides another path to release netns refcounts, previously
> netns_put() is the only choice, but it is not able to release all netns
> refcount, for e
From: Heiner Kallweit
Date: Fri, 10 May 2019 22:11:26 +0200
> Add missing page operation callbacks to few Realtek drivers.
> This also fixes a NPE after the referenced commit added code to the
> RTL8211E driver that uses phy_select_page().
>
> Fixes: f81dadbcf7fd ("net: phy: realtek: Add rtl8211
From: Stefano Garzarella
Date: Fri, 10 May 2019 14:58:37 +0200
> @@ -827,12 +827,20 @@ static bool virtio_transport_close(struct vsock_sock
> *vsk)
>
> void virtio_transport_release(struct vsock_sock *vsk)
> {
> + struct virtio_vsock_sock *vvs = vsk->trans;
> + struct virtio_vsock_bu
From: Petr Štetiar
Date: Fri, 10 May 2019 11:35:13 +0200
> this patch series is hopefuly the last series of the fixes which are related
> to the introduction of NVMEM support into of_get_mac_address.
>
> First patch is removing `nvmem-mac-address` property which was wrong idea as
> I've allocate
From: YueHaibing
Date: Fri, 10 May 2019 11:00:28 +0800
> Fix gcc build error:
>
> net/dsa/tag_brcm.c:211:16: error: brcm_prepend_netdev_ops undeclared here
> (not in a function); did you mean brcm_netdev_ops?
> DSA_TAG_DRIVER(brcm_prepend_netdev_ops);
> ^
> ./include/net/dsa.h:
On 05/10, Andrii Nakryiko wrote:
> On Fri, May 10, 2019 at 2:36 PM Stanislav Fomichev wrote:
> >
> > On 05/10, Andrii Nakryiko wrote:
> > > Depending on used versions of libbpf, Clang, and kernel, it's possible to
> > > have valid BPF object files with valid BTF information, that still won't
> > >
Alexei Starovoitov writes:
> On Fri, May 10, 2019 at 09:30:28AM +0100, Jiong Wang wrote:
>>
>> Alexei Starovoitov writes:
>>
>> > On Thu, May 09, 2019 at 01:32:30PM +0100, Jiong Wang wrote:
>> >>
>> >> Alexei Starovoitov writes:
>> >>
>> >> > On Wed, May 08, 2019 at 03:45:12PM +0100, Jiong W
There's currently a problem with toggling arp_validate on and off with an
active-backup bond. At the moment, you can start up a bond, like so:
modprobe bonding mode=1 arp_interval=100 arp_validate=0
arp_ip_targets=192.168.1.1
ip link set bond0 down
echo "ens4f0" > /sys/class/net/bond0/bonding/sla
The code was assuming the reset default of the delay control register
was to have delay disabled. This is what the datasheet shows as the
register's initial value. However, that's not actually true: the
default is controlled by the PHY's pin strapping.
If the interface mode is selected as RX or
The variables used to store u32 DT properties were signed ints. This
doesn't work properly if the value of the property were to overflow.
Use unsigned variables so this doesn't happen.
Cc: Andrew Lunn
Cc: Florian Fainelli
Cc: Heiner Kallweit
Signed-off-by: Trent Piepho
---
drivers/net/phy/dp
Generally, the output clock pin is only used for testing and only serves
as a source of RF noise after this. It could be used to daisy-chain
PHYs, but this is uncommon. Since the PHY can disable the output, make
doing so an option. I do this by adding another enumeration to the
allowed values of
Add a note to make it more clear how the driver behaves when "rgmii" vs
"rgmii-id", "rgmii-idrx", or "rgmii-idtx" interface modes are selected.
Cc: Rob Herring
Cc: Mark Rutland
Signed-off-by: Trent Piepho
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 6 ++
1 file changed, 6 in
The clock output is generally only used for testing and development and
not used to daisy-chain PHYs. It's just a source of RF noise afterward.
Add a mux value for "off". I've added it as another enumeration to the
output property. In the actual PHY, the mux and the output enable are
independen
On 05/10, Andrii Nakryiko wrote:
> Depending on used versions of libbpf, Clang, and kernel, it's possible to
> have valid BPF object files with valid BTF information, that still won't
> load successfully due to Clang emitting newer BTF features (e.g.,
> BTF_KIND_FUNC, .BTF.ext's line_info/func_info
On Fri, May 10, 2019 at 2:36 PM Stanislav Fomichev wrote:
>
> On 05/10, Andrii Nakryiko wrote:
> > Depending on used versions of libbpf, Clang, and kernel, it's possible to
> > have valid BPF object files with valid BTF information, that still won't
> > load successfully due to Clang emitting newe
On Friday, May 10, 2019 10:28:06 PM CEST, Heiner Kallweit wrote:
On 10.05.2019 17:05, Vicente Bergas wrote:
Hello,
there is a regression on linux v5.1-9573-gb970afcfcabd with a kernel null
pointer dereference.
The issue is the commit f81dadbcf7fd067baf184b63c179fc392bdb226e
net: phy: realtek: A
Depending on used versions of libbpf, Clang, and kernel, it's possible to
have valid BPF object files with valid BTF information, that still won't
load successfully due to Clang emitting newer BTF features (e.g.,
BTF_KIND_FUNC, .BTF.ext's line_info/func_info, BTF_KIND_DATASEC, etc), that
are not ye
On Fri, May 10, 2019 at 1:13 PM Alexei Starovoitov
wrote:
>
> On Fri, May 10, 2019 at 11:41:50AM -0700, Andrii Nakryiko wrote:
> > Depending on used versions of libbpf, Clang, and kernel, it's possible to
> > have valid BPF object files with valid BTF information, that still won't
> > load success
On Fri, May 10, 2019 at 05:05:13PM +0200, Vicente Bergas wrote:
> Hello,
> there is a regression on linux v5.1-9573-gb970afcfcabd with a kernel null
> pointer dereference.
> The issue is the commit f81dadbcf7fd067baf184b63c179fc392bdb226e
> net: phy: realtek: Add rtl8211e rx/tx delays config
> whi
On 5/10/19 1:11 PM, Heiner Kallweit wrote:
> Add missing page operation callbacks to few Realtek drivers.
> This also fixes a NPE after the referenced commit added code to the
> RTL8211E driver that uses phy_select_page().
>
> Fixes: f81dadbcf7fd ("net: phy: realtek: Add rtl8211e rx/tx delays conf
On Fri, May 10, 2019 at 01:12:49PM -0700, Santosh Shilimkar wrote:
> On 5/10/2019 12:47 PM, Jason Gunthorpe wrote:
> > On Fri, May 10, 2019 at 12:38:31PM -0700, Santosh Shilimkar wrote:
> > > On 5/10/2019 12:20 PM, Jason Gunthorpe wrote:
> > > > On Fri, May 10, 2019 at 11:58:42AM -0700, santosh.shi
On Fri, May 10, 2019 at 11:41:50AM -0700, Andrii Nakryiko wrote:
> Depending on used versions of libbpf, Clang, and kernel, it's possible to
> have valid BPF object files with valid BTF information, that still won't
> load successfully due to Clang emitting newer BTF features (e.g.,
> BTF_KIND_FUNC
Add missing page operation callbacks to few Realtek drivers.
This also fixes a NPE after the referenced commit added code to the
RTL8211E driver that uses phy_select_page().
Fixes: f81dadbcf7fd ("net: phy: realtek: Add rtl8211e rx/tx delays config")
Signed-off-by: Heiner Kallweit
---
drivers/net
On 5/10/2019 12:47 PM, Jason Gunthorpe wrote:
On Fri, May 10, 2019 at 12:38:31PM -0700, Santosh Shilimkar wrote:
On 5/10/2019 12:20 PM, Jason Gunthorpe wrote:
On Fri, May 10, 2019 at 11:58:42AM -0700, santosh.shilim...@oracle.com wrote:
On 5/10/19 11:07 AM, Jason Gunthorpe wrote:
On Fri, May
On Fri, May 10, 2019 at 09:30:28AM +0100, Jiong Wang wrote:
>
> Alexei Starovoitov writes:
>
> > On Thu, May 09, 2019 at 01:32:30PM +0100, Jiong Wang wrote:
> >>
> >> Alexei Starovoitov writes:
> >>
> >> > On Wed, May 08, 2019 at 03:45:12PM +0100, Jiong Wang wrote:
> >> >>
> >> >> I might be m
On Fri, May 10, 2019 at 12:38:31PM -0700, Santosh Shilimkar wrote:
> On 5/10/2019 12:20 PM, Jason Gunthorpe wrote:
> > On Fri, May 10, 2019 at 11:58:42AM -0700, santosh.shilim...@oracle.com
> > wrote:
> > > On 5/10/19 11:07 AM, Jason Gunthorpe wrote:
> > > > On Fri, May 10, 2019 at 11:02:35AM -070
On 5/10/2019 12:20 PM, Jason Gunthorpe wrote:
On Fri, May 10, 2019 at 11:58:42AM -0700, santosh.shilim...@oracle.com wrote:
On 5/10/19 11:07 AM, Jason Gunthorpe wrote:
On Fri, May 10, 2019 at 11:02:35AM -0700, santosh.shilim...@oracle.com wrote:
[...]
Why would you need to detect FS DAX mem
On Fri, May 10, 2019 at 11:58:42AM -0700, santosh.shilim...@oracle.com wrote:
> On 5/10/19 11:07 AM, Jason Gunthorpe wrote:
> > On Fri, May 10, 2019 at 11:02:35AM -0700, santosh.shilim...@oracle.com
> > wrote:
> > >
> > >
> > > On 5/10/19 10:55 AM, Jason Gunthorpe wrote:
> > > > On Fri, May 10,
On 5/10/19 11:07 AM, Jason Gunthorpe wrote:
On Fri, May 10, 2019 at 11:02:35AM -0700, santosh.shilim...@oracle.com wrote:
On 5/10/19 10:55 AM, Jason Gunthorpe wrote:
On Fri, May 10, 2019 at 09:11:24AM -0700, Santosh Shilimkar wrote:
On 5/10/2019 5:54 AM, Jason Gunthorpe wrote:
On Mon, Apr 2
Depending on used versions of libbpf, Clang, and kernel, it's possible to
have valid BPF object files with valid BTF information, that still won't
load successfully due to Clang emitting newer BTF features (e.g.,
BTF_KIND_FUNC, .BTF.ext's line_info/func_info, BTF_KIND_DATASEC, etc), that
are not ye
On Fri, May 10, 2019 at 08:24:03AM +, Andy Duan wrote:
> If MAC address read from nvmem cell and it is valid mac address,
> .of_get_mac_addr_nvmem() add new property "nvmem-mac-address" in
> ethernet node. Once user call .of_get_mac_address() to get MAC
> address again, it can read valid MAC ad
On Fri, May 10, 2019 at 08:31:02AM -0500, Shiraz Saleem wrote:
> On Wed, Mar 13, 2019 at 07:28:41AM -0600, Jason Gunthorpe wrote:
> >
> > > > Register a device driver to the driver core and wait for the driver
> > > > core to call that driver's probe method.
> > >
> > > Yes, the LAN PF driver is
On Fri, May 10, 2019 at 08:24:00AM +, Andy Duan wrote:
> ethernet controller driver call .of_get_mac_address() to get
> the mac address from devictree tree, if these properties are
> not present, then try to read from nvmem.
>
> For example, read MAC address from nvmem:
> of_get_mac_address()
On Fri, May 10, 2019 at 11:02:35AM -0700, santosh.shilim...@oracle.com wrote:
>
>
> On 5/10/19 10:55 AM, Jason Gunthorpe wrote:
> > On Fri, May 10, 2019 at 09:11:24AM -0700, Santosh Shilimkar wrote:
> > > On 5/10/2019 5:54 AM, Jason Gunthorpe wrote:
> > > > On Mon, Apr 29, 2019 at 04:37:19PM -070
On 5/10/19 10:55 AM, Jason Gunthorpe wrote:
On Fri, May 10, 2019 at 09:11:24AM -0700, Santosh Shilimkar wrote:
On 5/10/2019 5:54 AM, Jason Gunthorpe wrote:
On Mon, Apr 29, 2019 at 04:37:19PM -0700, Santosh Shilimkar wrote:
From: Hans Westgaard Ry
RDS doesn't support RDMA on memory apertur
On Fri, May 10, 2019 at 09:11:24AM -0700, Santosh Shilimkar wrote:
> On 5/10/2019 5:54 AM, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2019 at 04:37:19PM -0700, Santosh Shilimkar wrote:
> > > From: Hans Westgaard Ry
> > >
> > > RDS doesn't support RDMA on memory apertures that require On Demand
>
On Thu, 09 May 2019 21:57:49 -0700, John Fastabend wrote:
> @@ -2042,12 +2060,14 @@ void tls_sw_free_resources_tx(struct sock *sk)
> if (atomic_read(&ctx->encrypt_pending))
> crypto_wait_req(-EINPROGRESS, &ctx->async_wait);
>
> - release_sock(sk);
> + if (locked)
> +
Awhile ago I submitted this iproute2 patch:
https://patchwork.ozlabs.org/patch/784165/
And the corresponding kernel patch:
https://patchwork.ozlabs.org/patch/783696/
To allow the setting of arbitrary qdisc size table so that the packet
scheduler code in __qdisc_calculate_pkt_len charges the corre
On Thu, 09 May 2019 21:57:49 -0700, John Fastabend wrote:
> #ifdef CONFIG_TLS_DEVICE
> if (ctx->rx_conf == TLS_HW)
> tls_device_offload_cleanup_rx(sk);
> -
> - if (ctx->tx_conf != TLS_HW && ctx->rx_conf != TLS_HW) {
> -#else
> - {
> #endif
> +
> + if (ctx->tx_conf
From: Paolo Abeni
Date: Fri, 10 May 2019 11:37:58 +0200
> This reverts commit c7e0d6cca86581092cbbf2cd868b3601495554cf.
>
> It was agreed a slightly different fix via the selinux tree.
>
> v1 -> v2:
> - use the correct reverted commit hash
>
> Signed-off-by: Paolo Abeni
> ---
> Note: this is
On Fri, May 10, 2019 at 8:17 AM Lorenz Bauer wrote:
>
> On Fri, 10 May 2019 at 15:16, Andrii Nakryiko
> wrote:
> >
> > On Fri, May 10, 2019 at 2:46 AM Lorenz Bauer wrote:
> > >
> > > On Fri, 10 May 2019 at 05:37, Andrii Nakryiko wrote:
> > > >
> > > > Depending on used versions of libbpf, Clan
On 5/10/2019 6:02 AM, Jason Gunthorpe wrote:
On Mon, Apr 29, 2019 at 04:37:20PM -0700, Santosh Shilimkar wrote:
RDS doesn't support RDMA on memory apertures that require On Demand
Paging (ODP), such as FS DAX memory. A sysctl is added to indicate
whether RDMA requiring ODP is supported.
Revi
On 5/10/2019 5:54 AM, Jason Gunthorpe wrote:
On Mon, Apr 29, 2019 at 04:37:19PM -0700, Santosh Shilimkar wrote:
From: Hans Westgaard Ry
RDS doesn't support RDMA on memory apertures that require On Demand
Paging (ODP), such as FS DAX memory. User applications can try to use
RDS to perform RDMA
On Fri, 10 May 2019 07:16:44 -0700, John Fastabend wrote:
> Jakub Kicinski wrote:
> > At the time padding_length() is called the record header
> > is still part of the message. If malicious TLS 1.3 peer
> > sends an all-zero record padding_length() will stop at
> > the record header, and return fu
On Fri, 10 May 2019 at 15:16, Andrii Nakryiko wrote:
>
> On Fri, May 10, 2019 at 2:46 AM Lorenz Bauer wrote:
> >
> > On Fri, 10 May 2019 at 05:37, Andrii Nakryiko wrote:
> > >
> > > Depending on used versions of libbpf, Clang, and kernel, it's possible to
> > > have valid BPF object files with v
Synchronise the bpf.h header under tools, to report the fixes and
additions recently brought to the documentation for the BPF helpers.
Signed-off-by: Quentin Monnet
Acked-by: Jakub Kicinski
---
tools/include/uapi/linux/bpf.h | 145 +
1 file changed, 75 in
"Underlaying packet buffer" should be an "underlying" one, in the
warning about invalidated data and data_end pointers. Through
copy-and-paste, the typo occurred no fewer than 19 times in the
documentation. Let's fix it.
Signed-off-by: Quentin Monnet
Acked-by: Jakub Kicinski
---
include/uapi/li
This commit brings many minor fixes to the documentation for BPF helper
functions. Mostly, this is limited to formatting fixes and improvements.
In particular, fix broken formatting for bpf_skb_adjust_room().
Besides formatting, replace the mention of "bpf_fullsock()" (that is not
associated with
The script broke on parsing function prototype for bpf_strtoul(). This
is because the last argument for the function is a pointer to an
"unsigned long". The current version of the script only accepts "const"
and "struct", but not "unsigned", at the beginning of argument types
made of several words.
Another round of fixes for the doc in the BPF UAPI header, which can be
turned into a manual page. First patch is the most important, as it fixes
parsing for the bpf_strtoul() helper doc. Following patches are formatting
fixes (nitpicks, mostly). The last one updates the copy of the header,
located
On Fri, May 10, 2019 at 2:46 AM Lorenz Bauer wrote:
>
> On Fri, 10 May 2019 at 05:37, Andrii Nakryiko wrote:
> >
> > Depending on used versions of libbpf, Clang, and kernel, it's possible to
> > have valid BPF object files with valid BTF information, that still won't
> > load successfully due to
Jakub Kicinski wrote:
> At the time padding_length() is called the record header
> is still part of the message. If malicious TLS 1.3 peer
> sends an all-zero record padding_length() will stop at
> the record header, and return full length of the data
> including the tail_size.
>
> Subsequent sub
Jakub Kicinski wrote:
> Commit 4504ab0e6eb8 ("net/tls: Inform user space about send buffer
> availability")
> made us report write_space regardless whether partial record
> push was successful or not. Remove the now unused return value
> to clean up the following W=1 warning:
>
> net/tls/tls_dev
On Wed, Mar 13, 2019 at 07:28:41AM -0600, Jason Gunthorpe wrote:
>
> > > Register a device driver to the driver core and wait for the driver
> > > core to call that driver's probe method.
> >
> > Yes, the LAN PF driver is the software component exposing and managing the
> > bus, so it is the one
On Mon, Apr 29, 2019 at 04:37:20PM -0700, Santosh Shilimkar wrote:
> RDS doesn't support RDMA on memory apertures that require On Demand
> Paging (ODP), such as FS DAX memory. A sysctl is added to indicate
> whether RDMA requiring ODP is supported.
>
> Reviewed-by: Håkon Bugge
> Reviewed-tested-b
On Mon, Apr 29, 2019 at 04:37:19PM -0700, Santosh Shilimkar wrote:
> From: Hans Westgaard Ry
>
> RDS doesn't support RDMA on memory apertures that require On Demand
> Paging (ODP), such as FS DAX memory. User applications can try to use
> RDS to perform RDMA over such memories and since it doesn'
> > > +/* Serial Management Interface (SMI) uses the following frame format:
> > > + *
> > > + * preamble|start|Read/Write| PHY | REG |TA| Data bits
> > > | Idle
> > > + * |frame| OP code |address |address| |
> > > |
> > > + * read | 32x1´s | 01
On Fri, May 10, 2019 at 01:28:22PM +0200, Petr Štetiar wrote:
> Andy Duan [2019-05-10 08:23:58]:
>
> Hi Andy,
>
> you've probably forget to Cc some maintainers and mailing lists, so I'm
> adding them now to the Cc loop. This patch series should be posted against
> net-next tree as per netdev FAQ[0
Andy Duan [2019-05-10 08:23:58]:
Hi Andy,
you've probably forget to Cc some maintainers and mailing lists, so I'm
adding them now to the Cc loop. This patch series should be posted against
net-next tree as per netdev FAQ[0], but you've to wait little bit as
net-next is currently closed for the n
On Thu, May 09, 2019 at 09:39:13AM -0700, David Miller wrote:
> From: Neil Horman
> Date: Thu, 9 May 2019 07:32:35 -0400
>
> > This is definately a valid cleanup, but I wonder if it wouldn't be better
> > to,
> > instead of removing it, to use it. We have 2 locations where we actually
> > call
Hi Marc,
Stefan-gabriel Mirea was successfully validated this patch set on an S32V234
based board, and I have improved the driver with his valuable feedback.
I also split the patch set into small particle size that will easy your
patch review.
Regards,
Joakim Zhang
Dong Aisheng (3):
can: flex
We need to use alloc_canfd_skb() for CAN FD frames and alloc_can_skb()
for CAN classic frames. So we have to alloc skb in flexcan_mailbox_read().
Signed-off-by: Joakim Zhang
ChangeLog:
--
V1->V2:
*None
V2->V3:
*Change the way to allocate skb
---
drivers/net/can/flexcan.c
From: Dong Aisheng
Bit timing always set in CBT register other than CTRL1 register when CANFD
supports BRS, it will extend the range of all CAN bit timing variables
(PRESDIV, PROPSEG, PSEG1, PSEG2 and RJW), which will improve the bit
timing accuracy.
Signed-off-by: Dong Aisheng
Signed-off-by: J
ISO CAN FD is introduced to increase the failture detection capability
than non-ISO CAN FD. The non-ISO CAN FD is still supported by FlexCAN so
that it can be used mainly during an intermediate phase, for evaluation
and development purposes.
Therefore, it is strongly recommended to configure FlexC
From: Dong Aisheng
This patch intends to add CAN FD BitRate Switch(BRS) support in driver.
Signed-off-by: Joakim Zhang
Signed-off-by: Dong Aisheng
ChangeLog:
--
V2->V3:
*split from another patch
---
drivers/net/can/flexcan.c | 9 -
1 file changed, 8 insertions(+), 1 d
From: Dong Aisheng
The Flexcan on i.MX8QM supports CAN FD protocol.
Signed-off-by: Dong Aisheng
Signed-off-by: Joakim Zhang
ChangeLog:
--
V1->V2:
*None
V2->V3:
*None
---
drivers/net/can/flexcan.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/c
This patch intends to add CAN FD mode support in driver, it means that
payload size can extend up to 64 bytes.
NOTE: Bit rate switch (BRS) enabled by system reset when it enables CAN
FD mode (explicitly set BRS again in driver). So CAN hardware has support
BRS, but now driver has not support it du
This patch prepares for CAN FD mode, using struct canfd_frame can both
for normal format frame and fd format frame.
Signed-off-by: Joakim Zhang
ChangeLog:
--
V2->V3:
*New patch, split from other patch
---
drivers/net/can/flexcan.c| 14 +++---
drivers/net/can/rx-offlo
On Fri, 10 May 2019 at 05:37, Andrii Nakryiko wrote:
>
> Depending on used versions of libbpf, Clang, and kernel, it's possible to
> have valid BPF object files with valid BTF information, that still won't
> load successfully due to Clang emitting newer BTF features (e.g.,
> BTF_KIND_FUNC, .BTF.ex
In commit d01f449c008a ("of_net: add NVMEM support to
of_get_mac_address") I've added `nvmem-mac-address` property which was
wrong idea as I've allocated the property with devm_kzalloc and then
added it to DT, so then 2 entities would be refcounting the allocation.
So if the driver unbinds, the buf
On Fri, 2019-05-10 at 11:27 +0200, Paolo Abeni wrote:
> This reverts commit 7301017039d68c920cb9120c035a1a0df3e6b30d.
>
> It was agreed a slightly different fix via the selinux tree.
>
> Signed-off-by: Paolo Abeni
Whoops... this references the wrong hash - the local one instead of the
'-net' tr
This reverts commit c7e0d6cca86581092cbbf2cd868b3601495554cf.
It was agreed a slightly different fix via the selinux tree.
v1 -> v2:
- use the correct reverted commit hash
Signed-off-by: Paolo Abeni
---
Note: this is targeting the 'net' tree
---
security/selinux/hooks.c | 8
1 file c
Hi,
this patch series is hopefuly the last series of the fixes which are related
to the introduction of NVMEM support into of_get_mac_address.
First patch is removing `nvmem-mac-address` property which was wrong idea as
I've allocated the property with devm_kzalloc and then added it to DT, so the
This reverts commit 7301017039d68c920cb9120c035a1a0df3e6b30d.
It was agreed a slightly different fix via the selinux tree.
Signed-off-by: Paolo Abeni
---
Note: this is targeting the 'net' tree
---
security/selinux/hooks.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Alexei Starovoitov writes:
> On Thu, May 09, 2019 at 01:32:30PM +0100, Jiong Wang wrote:
>>
>> Alexei Starovoitov writes:
>>
>> > On Wed, May 08, 2019 at 03:45:12PM +0100, Jiong Wang wrote:
>> >>
>> >> I might be misunderstanding your points, please just shout if I am wrong.
>> >>
>> >> Supp
ethernet controller driver call .of_get_mac_address() to get
the mac address from devictree tree, if these properties are
not present, then try to read from nvmem.
For example, read MAC address from nvmem:
of_get_mac_address()
of_get_mac_addr_nvmem()
nvmem_get_mac_address()
If MAC address read from nvmem cell and it is valid mac address,
.of_get_mac_addr_nvmem() add new property "nvmem-mac-address" in
ethernet node. Once user call .of_get_mac_address() to get MAC
address again, it can read valid MAC address from device tree in
directly.
Signed-off-by: Fugang Duan
--
Currently, of_get_mac_address supports NVMEM, some platforms
MAC address that read from NVMEM efuse requires to swap bytes
order, so add new property "nvmem_macaddr_swap" to specify the
behavior. If the MAC address is valid from NVMEM, add new property
"nvmem-mac-address" in ethernet node.
Update
ethernet controller driver call .of_get_mac_address() to get
the mac address from devictree tree, if these properties are
not present, then try to read from nvmem. i.MX6x/7D/8MQ/8MM
platforms ethernet MAC address read from nvmem ocotp eFuses,
but it requires to swap the six bytes order.
The patch
On Thu, May 09, 2019 at 04:48:44PM +0200, Andrew Lunn wrote:
> On Wed, May 08, 2019 at 11:13:29PM +0200, Michael Grzeschik wrote:
> > Cc: tristram...@microchip.com
> > Signed-off-by: Michael Grzeschik
> > ---
> > drivers/net/dsa/microchip/Kconfig | 16 +
> > drivers/net/dsa/microchip/Make
On Thu, May 09, 2019 at 04:29:25PM +0200, Andrew Lunn wrote:
> On Wed, May 08, 2019 at 11:13:28PM +0200, Michael Grzeschik wrote:
> > Some microchip phys support the Serial Management Interface Protocol
> > (SMI) for the configuration of the extended register set. We add
> > MII_ADDR_SMI0 as an ava
On Thu, May 09, 2019 at 11:07:45PM +0200, Andrew Lunn wrote:
> On Thu, May 09, 2019 at 10:55:29PM +0200, Heiner Kallweit wrote:
> > On 09.05.2019 22:29, Uwe Kleine-König wrote:
> > > I have a board here that has a KSZ8051MLL (datasheet:
> > > http://ww1.microchip.com/downloads/en/DeviceDoc/ksz8051m
99 matches
Mail list logo
