* RE: [PATCH lora-next 01/10] net: lora: sx1301: add register, bit-fields, and helpers for regmap
From: Ben Whitten @ 2018-08-08 15:52 UTC (permalink / raw)
To: Andreas Färber, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org
In-Reply-To: <f0b0a89d-6e32-10e6-4270-0f504d19bc6c@suse.de>
> Subject: Re: [PATCH lora-next 01/10] net: lora: sx1301: add
> register, bit-fields, and helpers for regmap
>
> Am 08.08.2018 um 14:32 schrieb Ben Whitten:
> >>> drivers/net/lora/Kconfig | 1 +
> >>> drivers/net/lora/sx1301.c | 282
> >> +++++++++++++++++++++++++++++++++++++++++++-
> --
> >>> drivers/net/lora/sx1301.h | 169
> >> +++++++++++++++++++++++++++
> >>> 3 files changed, 439 insertions(+), 13 deletions(-)
> >>> create mode 100644 drivers/net/lora/sx1301.h
> >>
> >> My main concern about this patch is its sheer size.
> Normally
> >> for
> >> #defines the rule is not to add unused ones. Here I see
> for
> >> example FSK
> >> RSSI fields that we're surely not using yet. Any chance to
> >> strip this
> >> down some more?
> >
> > Sure, I'll strip the reg_fields down to those only required
> for
> > loading firmware and setting clocks that will be used in the
> > immediate term. This does clutter the driver a bit
> > unnecessarily at the moment.
> > I would like to keep the full register dump in the header
> file
> > though as its self-contained and gives a full picture of the
> chip.
>
> Could you do that in more steps though? I'm thinking,
> convert only the
> registers in use to regmap (that'll make it easier to review),
> then add
> more registers, then convert to regmap fields?
I split the conversion function by function but we can probably go
further if you think it helpful.
Is it more the addition of the replacement register defines that you
would like to correlate with what's being removed, so you can see
in one patch that this register has the same page and the same
address in the new system?
The problem I face is that these conversions are almost blind as
when I run on my hardware I either oops with the sx1301_read
or the cal firmware doesn't verify so I can't finish probe. I only
get a full sx1301 module probe pass on physical hardware when
I get right to the end of the series where it's all replaced with
regmap.
Regards,
Ben Whitten
^ permalink raw reply
* Re: [PATCH iproute2] ip link: don't stop batch processing
From: Stephen Hemminger @ 2018-08-08 16:26 UTC (permalink / raw)
To: Dave Taht; +Cc: mcroce, Linux Kernel Network Developers
In-Reply-To: <CAA93jw7+A2Fp+vsra1=cT+cP6BnvpNiiCJqhtqZZBkRzVdZB6w@mail.gmail.com>
On Fri, 3 Aug 2018 11:08:58 -0700
Dave Taht <dave.taht@gmail.com> wrote:
> On Fri, Aug 3, 2018 at 10:50 AM Matteo Croce <mcroce@redhat.com> wrote:
> >
> > When 'ip link show dev DEVICE' is processed in a batch mode, ip exits
> > and stop processing further commands.
> > This because ipaddr_list_flush_or_save() calls exit() to avoid printing
> > the link information twice.
> > Replace the exit with a classic goto out instruction.
> >
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
>
> one thing I noticed in iproute2-next last week is that
>
> ( echo qdisc show dev eno1; sleep 5; echo qdisc show dev eno1; ) | tc -b -
>
> batches the whole thing up to emerge on exit, only.
>
> It didn't used to do that, the output of every command came out as it
> completed. I used to use that to timestamp and save the overhead of
> invoking the tc utility on openwrt while monitoring qdisc stats in
> https://github.com/tohojo/flent/blob/master/misc/tc_iterate.c
There used to be lots of fflush(stdout) in each sub command but lots of these
got dropped in JSON updates.
I just added one back in after each batch command that should fix what you are seeing.
^ permalink raw reply
* Re: [PATCH iproute2] ip link: don't stop batch processing
From: Stephen Hemminger @ 2018-08-08 16:27 UTC (permalink / raw)
To: Matteo Croce; +Cc: netdev
In-Reply-To: <20180803174933.24600-1-mcroce@redhat.com>
On Fri, 3 Aug 2018 19:49:33 +0200
Matteo Croce <mcroce@redhat.com> wrote:
> When 'ip link show dev DEVICE' is processed in a batch mode, ip exits
> and stop processing further commands.
> This because ipaddr_list_flush_or_save() calls exit() to avoid printing
> the link information twice.
> Replace the exit with a classic goto out instruction.
>
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
> ---
> ip/ipaddress.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index 6c306ab7..b7b78f6e 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -1920,7 +1920,7 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
> exit(1);
> }
> delete_json_obj();
> - exit(0);
> + goto out;
> }
>
> if (filter.family != AF_PACKET) {
Applied
^ permalink raw reply
* Re: [PATCH 00/28] at24: remove at24_platform_data
From: Bartosz Golaszewski @ 2018-08-08 16:27 UTC (permalink / raw)
To: Wolfram Sang
Cc: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner
In-Reply-To: <20180808155548.s7p4xqsjywz3psrj@ninjato>
2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>:
> On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> This is a follow-up to the previously rejected series[1] which partially
>> removed the at24_platform_data structure. After further development and
>> taking reviews into account, this series finally removes that struct
>> completely but not without touching many different parts of the code
>> base.
>>
>> Since I took over maintainership of the at24 driver I've been working
>> towards removing at24_platform_data in favor for device properties.
>
> Wooha, nice work. I can't really comment on it but wondered how you want
> to upstream it (after reviews)? Pull request of an immutable branch for
> nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
> it. Probably same situation for arm-soc...
>
I initially wanted to merge small parts of it starting with v4.18, but
there were some voices against merging APIs without users. I'm not
sure how it should go in. There'll be a need for multiple immutable
branches most probably...
Bart
^ permalink raw reply
* Re: [PATCH 00/33] net: ethernet: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-08-08 16:26 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-kernel, linux-net-drivers, ecree, bkenward, jes,
linux-acenic, michael.chan, nicolas.ferre, derek.chickles,
satananda.burla, felix.manlunas, raghu.vatsavayi, ganeshgr,
santosh, sgoutham, rric, linux-arm-kernel, linux-parisc,
sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
yisen.zhuang, salil.mehta, jeffrey.t.kirsher, intel-wired-lan,
tariqt, l
In-Reply-To: <20180807.175931.200772329178253653.davem@davemloft.net>
On 8/7/18 7:59 PM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Tue, 7 Aug 2018 18:09:00 -0500
>
>> In preparation to enabling -Wimplicit-fallthrough, this patchset aims
>> to add some annotations in order to mark switch cases where we are
>> expecting to fall through.
>
> Ok, I went through all of these and they look good.
>
> If any are not correct we can revert/fix.
>
Yep. If anything is reported, I'll take a look right away.
> Series applied, thanks.
>
Thanks
^ permalink raw reply
* Re: [PATCH 03/28] nvmem: add a notifier chain
From: Bartosz Golaszewski @ 2018-08-08 16:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner
In-Reply-To: <20180808161353.GF7275@lunn.ch>
2018-08-08 18:13 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
> On Wed, Aug 08, 2018 at 05:31:25PM +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Add a blocking notifier chain with two events (add and remove) so that
>> users can get notified about the addition of nvmem devices they're
>> waiting for.
>>
>> We'll use this instead of the at24 setup callback in the mityomapl138
>> board file.
>
> Hi Bartosz
>
> What context is this notifier chain called in?
>
> I did something similar using the i2c notifier to try to work around
> the impending disappearing of the setup callback. But i got lockdep
> splats, because the notifier was called while some locks were being
> held, so it was not possible to register other i2c devices.
>
> The at24 setup callback is done as part of probe, so no important
> locks are held. Are any locks held when this notifier chain is called?
>
> Thanks
> Andrew
In the case of at24 it would be called from at24_probe() ->
nvmem_register() in process context. Would you mind testing it? Would
be great to see if it works on multiple setups.
Bart
^ permalink raw reply
* Re: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720
From: Andrew Lunn @ 2018-08-08 16:58 UTC (permalink / raw)
To: Marek Behún
Cc: linux-arm-kernel, netdev, Gregory CLEMENT, Tomas Hlavacek,
Russell King - ARM Linux
In-Reply-To: <20180808152706.21727-7-marek.behun@nic.cz>
On Wed, Aug 08, 2018 at 05:27:05PM +0200, Marek Behún wrote:
> For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the
> networking driver behaves weirdly when using napi_gro_receive.
>
> For example downloading a big file from a local network (low ping) is
> fast, but when downloading from a remote server (higher ping), the
> download speed is at first high but drops rapidly to almost nothing or
> absolutely nothing.
>
> This is fixed when using netif_receive_skb instead of napi_gro_receive.
Before doing this, we should really understand what is going on. It is
probably just a driver bug which needs fixing. And GRO should be good
for performance, so we do want to use it, if possible.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] netfilter: nfnetlink_osf: fix using plain integer as NULL warning
From: Pablo Neira Ayuso @ 2018-08-08 17:05 UTC (permalink / raw)
To: Wei Yongjun
Cc: Jozsef Kadlecsik, Florian Westphal, netfilter-devel, coreteam,
netdev, kernel-janitors
In-Reply-To: <1533698624-107304-1-git-send-email-weiyongjun1@huawei.com>
On Wed, Aug 08, 2018 at 03:23:44AM +0000, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> net/netfilter/nfnetlink_osf.c:274:24: warning:
> Using plain integer as NULL pointer
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v1 1/1] net/tls: Combined memory allocation for decryption request
From: Dave Watson @ 2018-08-08 17:07 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180808130630.13568-2-vakul.garg@nxp.com>
On 08/08/18 06:36 PM, Vakul Garg wrote:
> For preparing decryption request, several memory chunks are required
> (aead_req, sgin, sgout, iv, aad). For submitting the decrypt request to
> an accelerator, it is required that the buffers which are read by the
> accelerator must be dma-able and not come from stack. The buffers for
> aad and iv can be separately kmalloced each, but it is inefficient.
> This patch does a combined allocation for preparing decryption request
> and then segments into aead_req || sgin || sgout || iv || aad.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> ---
> + n_sgout = sg_nents(out_sg);
> +
> + n_sgin = skb_nsg(skb, rxm->offset + tls_ctx->rx.prepend_size,
> + rxm->full_len - tls_ctx->rx.prepend_size);
> + } else {
> +no_zerocopy:
label is unused now
^ permalink raw reply
* [PATCH bpf 0/3] Couple of sockmap fixes
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
Two sockmap fixes in bpf_tcp_sendmsg(), and one fix for the
sockmap kernel selftest. Thanks!
Daniel Borkmann (3):
bpf, sockmap: fix bpf_tcp_sendmsg sock error handling
bpf, sockmap: fix leak in bpf_tcp_sendmsg wait for mem path
bpf, sockmap: fix cork timeout for select due to epipe
kernel/bpf/sockmap.c | 9 ++++++---
tools/testing/selftests/bpf/test_sockmap.c | 2 +-
2 files changed, 7 insertions(+), 4 deletions(-)
--
2.9.5
^ permalink raw reply
* [PATCH bpf 2/3] bpf, sockmap: fix leak in bpf_tcp_sendmsg wait for mem path
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
In-Reply-To: <20180808172315.4710-1-daniel@iogearbox.net>
In bpf_tcp_sendmsg() the sk_alloc_sg() may fail. In the case of
ENOMEM, it may also mean that we've partially filled the scatterlist
entries with pages. Later jumping to sk_stream_wait_memory()
we could further fail with an error for several reasons, however
we miss to call free_start_sg() if the local sk_msg_buff was used.
Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index f7360c4..c4d75c5 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1048,7 +1048,7 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
while (msg_data_left(msg)) {
- struct sk_msg_buff *m;
+ struct sk_msg_buff *m = NULL;
bool enospc = false;
int copy;
@@ -1116,8 +1116,11 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
wait_for_memory:
err = sk_stream_wait_memory(sk, &timeo);
- if (err)
+ if (err) {
+ if (m && m != psock->cork)
+ free_start_sg(sk, m);
goto out_err;
+ }
}
out_err:
if (err < 0)
--
2.9.5
^ permalink raw reply related
* [PATCH bpf 1/3] bpf, sockmap: fix bpf_tcp_sendmsg sock error handling
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
In-Reply-To: <20180808172315.4710-1-daniel@iogearbox.net>
While working on bpf_tcp_sendmsg() code, I noticed that when a
sk->sk_err is set we error out with err = sk->sk_err. However
this is problematic since sk->sk_err is a positive error value
and therefore we will neither go into sk_stream_error() nor will
we report an error back to user space. I had this case with EPIPE
and user space was thinking sendmsg() succeeded since EPIPE is
a positive value, thinking we submitted 32 bytes. Fix it by
negating the sk->sk_err value.
Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 98fb793..f7360c4 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1053,7 +1053,7 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
int copy;
if (sk->sk_err) {
- err = sk->sk_err;
+ err = -sk->sk_err;
goto out_err;
}
--
2.9.5
^ permalink raw reply related
* [PATCH bpf 3/3] bpf, sockmap: fix cork timeout for select due to epipe
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
In-Reply-To: <20180808172315.4710-1-daniel@iogearbox.net>
I ran into the same issue as a009f1f396d0 ("selftests/bpf:
test_sockmap, timing improvements") where I had a broken
pipe error on the socket due to remote end timing out on
select and then shutting down it's sockets while the other
side was still sending. We may need to do a bigger rework
in general on the test_sockmap.c, but for now increase it
to a more suitable timeout.
Fixes: a18fda1a62c3 ("bpf: reduce runtime of test_sockmap tests")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
---
tools/testing/selftests/bpf/test_sockmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c
index 9e78df2..0c7d9e5 100644
--- a/tools/testing/selftests/bpf/test_sockmap.c
+++ b/tools/testing/selftests/bpf/test_sockmap.c
@@ -354,7 +354,7 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
while (s->bytes_recvd < total_bytes) {
if (txmsg_cork) {
timeout.tv_sec = 0;
- timeout.tv_usec = 1000;
+ timeout.tv_usec = 300000;
} else {
timeout.tv_sec = 1;
timeout.tv_usec = 0;
--
2.9.5
^ permalink raw reply related
* Re: [PATCH v6 8/9] net/mlx5: Do not call pcie_print_link_status()
From: Leon Romanovsky @ 2018-08-08 17:27 UTC (permalink / raw)
To: Alex G.
Cc: Tal Gilboa, linux-pci, bhelgaas, jakub.kicinski, keith.busch,
alex_gagniuc, austin_bolen, shyam_iyer, Ariel Elior,
everest-linux-l2, David S. Miller, Michael Chan, Ganesh Goudar,
Jeff Kirsher, Tariq Toukan, Saeed Mahameed, Dirk van der Merwe,
netdev, linux-kernel, intel-wired-lan, linux-rdma, oss-drivers
In-Reply-To: <79264a38-e3e4-d270-95df-a09047f7a15e@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2996 bytes --]
On Wed, Aug 08, 2018 at 11:33:51AM -0500, Alex G. wrote:
>
>
> On 08/08/2018 10:56 AM, Tal Gilboa wrote:
> > On 8/8/2018 6:41 PM, Leon Romanovsky wrote:
> > > On Wed, Aug 08, 2018 at 05:23:12PM +0300, Tal Gilboa wrote:
> > > > On 8/8/2018 9:08 AM, Leon Romanovsky wrote:
> > > > > On Mon, Aug 06, 2018 at 06:25:42PM -0500, Alexandru Gagniuc wrote:
> > > > > > This is now done by the PCI core to warn of sub-optimal bandwidth.
> > > > > >
> > > > > > Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> > > > > > ---
> > > > > > drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ----
> > > > > > 1 file changed, 4 deletions(-)
> > > > > >
> > > > >
> > > > > Thanks,
> > > > > Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
> > > > >
> > > >
> > > > Alex,
> > > > I loaded mlx5 driver with and without these series. The report
> > > > in dmesg is
> > > > now missing. From what I understood, the status should be
> > > > reported at least
> > > > once, even if everything is in order.
> > >
> > > It is not what this series is doing and it removes prints completely if
> > > fabric can deliver more than card is capable.
> > >
> > > > We need this functionality to stay.
> > >
> > > I'm not sure that you need this information in driver's dmesg output,
> > > but most probably something globally visible and accessible per-pci
> > > device.
> >
> > Currently we have users that look for it. If we remove the dmesg print
> > we need this to be reported elsewhere. Adding it to sysfs for example
> > should be a valid solution for our case.
>
> I think a stop-gap measure is to leave the pcie_print_link_status() call in
> drivers that really need it for whatever reason. Implementing a reliable
> reporting through sysfs might take some tinkering, and I don't think it's a
> sufficient reason to block the heart of this series -- being able to detect
> bottlenecks and link downtraining.
IMHO, you did right change and it is better to replace this print to some
more generic solution now while you are doing it and don't leave leftovers.
Thanks
>
> Alex
>
> > >
> > > >
> > > > net-next (dmesg output for 07:00.0):
> > > > [270498.625351] mlx5_core 0000:07:00.0: firmware version: 14.22.4020
> > > > [270498.632130] mlx5_core 0000:07:00.0: 63.008 Gb/s available
> > > > PCIe bandwidth
> > > > (8 GT/s x8 link)
> > > > [270499.169533] (0000:07:00.0): E-Switch: Total vports 9, per vport: max
> > > > uc(1024) max mc(16384)
> > > > [270499.182358] mlx5_core 0000:07:00.0: Port module event:
> > > > module 0, Cable
> > > > plugged
> > > >
> > > > net-next + patches (dmesg output for 07:00.0):
> > > > [ 331.608472] mlx5_core 0000:07:00.0: firmware version: 14.22.4020
> > > > [ 332.564938] (0000:07:00.0): E-Switch: Total vports 9, per vport: max
> > > > uc(1024) max mc(16384)
> > > > [ 332.616271] mlx5_core 0000:07:00.0: Port module event: module
> > > > 0, Cable
> > > > plugged
> > > >
> > > >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] fix build for MediaTek MT7610U USB wireless dongle
From: valdis.kletnieks @ 2018-08-08 20:16 UTC (permalink / raw)
To: Kalle Valo, David S. Miller; +Cc: netdev, linux-kernel, linux-wireless
The mt76x0 driver requires the mt76 core driver to actually function.
So add a 'select' to avoid embarrassing 'symbol unknown' errors
when attempting to modprobe it in a module tree that doesn't
include mt76.ko
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
---
Still need to figure out why it totally fails to see the 5gz band,
it works find on 2.4 but ends up locked at 72mbits/sec. Works
OK otherwise...
diff --git a/drivers/net/wireless/mediatek/mt76/Kconfig b/drivers/net/wireless/mediatek/mt76/Kconfig
index 850611ad347a..b6c5f17dca30 100644
--- a/drivers/net/wireless/mediatek/mt76/Kconfig
+++ b/drivers/net/wireless/mediatek/mt76/Kconfig
@@ -11,6 +11,7 @@ config MT76x2_COMMON
config MT76x0U
tristate "MediaTek MT76x0U (USB) support"
+ select MT76_CORE
depends on MAC80211
depends on USB
help
^ permalink raw reply related
* Re: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720
From: Dave Taht @ 2018-08-08 17:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: marek.behun, linux-arm-kernel, Linux Kernel Network Developers,
gregory.clement, tomas.hlavacek, linux
In-Reply-To: <20180808165846.GK7275@lunn.ch>
On Wed, Aug 8, 2018 at 10:00 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Aug 08, 2018 at 05:27:05PM +0200, Marek Behún wrote:
> > For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the
> > networking driver behaves weirdly when using napi_gro_receive.
> >
> > For example downloading a big file from a local network (low ping) is
> > fast, but when downloading from a remote server (higher ping), the
> > download speed is at first high but drops rapidly to almost nothing or
> > absolutely nothing.
> >
> > This is fixed when using netif_receive_skb instead of napi_gro_receive.
>
> Before doing this, we should really understand what is going on. It is
> probably just a driver bug which needs fixing. And GRO should be good
> for performance, so we do want to use it, if possible.
I'd just disable it and worry about it later. The software gro in the
mvneta would batch up 64k and is one of the reasons why sch_cake does
gso splitting by default. (64k unsplit, downshifted to 1mbit = ~540ms
of latency). If this mvneta facility is in addition buggy, that
explains some puzzling things I've seen in various benchmarks. thx for
the steer as to what to look for!
IMHO: in general gro looks good on dumb single stream benchmarks, not
as useful on mixed routed traffic with more entropy, and batching
clutters up the mvneta receive path that otherwise could be draining
the rx ring and spitting packets into the rest of the system faster.
The mvneta is mostly (?) used on routing devices.
>
> Andrew
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
^ permalink raw reply
* Re: [PATCH 28/28] eeprom: at24: kill at24_platform_data
From: Andy Shevchenko @ 2018-08-08 18:03 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-29-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> There are no more users of at24_platform_data. Remove the relevant
> header and modify the driver code to not use it anymore.
>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
If you want me to test this on Intel Galileo Gen 2 board, give me a
public tree from where I can pull.
Thanks.
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> MAINTAINERS | 1 -
> drivers/misc/eeprom/at24.c | 127 +++++++++++++----------------
> include/linux/platform_data/at24.h | 60 --------------
> 3 files changed, 57 insertions(+), 131 deletions(-)
> delete mode 100644 include/linux/platform_data/at24.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7cebd5bba8a8..8eb87a3548f8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2328,7 +2328,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
> S: Maintained
> F: Documentation/devicetree/bindings/eeprom/at24.txt
> F: drivers/misc/eeprom/at24.c
> -F: include/linux/platform_data/at24.h
>
> ATA OVER ETHERNET (AOE) DRIVER
> M: "Ed L. Cashin" <ed.cashin@acm.org>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index f5cc517d1131..93642b4b47c5 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -22,10 +22,24 @@
> #include <linux/i2c.h>
> #include <linux/nvmem-provider.h>
> #include <linux/regmap.h>
> -#include <linux/platform_data/at24.h>
> #include <linux/pm_runtime.h>
> #include <linux/gpio/consumer.h>
>
> +/* Address pointer is 16 bit. */
> +#define AT24_FLAG_ADDR16 BIT(7)
> +/* sysfs-entry will be read-only. */
> +#define AT24_FLAG_READONLY BIT(6)
> +/* sysfs-entry will be world-readable. */
> +#define AT24_FLAG_IRUGO BIT(5)
> +/* Take always 8 addresses (24c00). */
> +#define AT24_FLAG_TAKE8ADDR BIT(4)
> +/* Factory-programmed serial number. */
> +#define AT24_FLAG_SERIAL BIT(3)
> +/* Factory-programmed mac address. */
> +#define AT24_FLAG_MAC BIT(2)
> +/* Does not auto-rollover reads to the next slave address. */
> +#define AT24_FLAG_NO_RDROL BIT(1)
> +
> /*
> * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
> * Differences between different vendor product lines (like Atmel AT24C or
> @@ -124,10 +138,6 @@ MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");
> usleep_range(1000, 1500), op_time = jiffies)
>
> struct at24_chip_data {
> - /*
> - * these fields mirror their equivalents in
> - * struct at24_platform_data
> - */
> u32 byte_len;
> u8 flags;
> };
> @@ -467,46 +477,11 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
> return 0;
> }
>
> -static void at24_properties_to_pdata(struct device *dev,
> - struct at24_platform_data *chip)
> -{
> - int err;
> - u32 val;
> -
> - if (device_property_present(dev, "read-only"))
> - chip->flags |= AT24_FLAG_READONLY;
> - if (device_property_present(dev, "no-read-rollover"))
> - chip->flags |= AT24_FLAG_NO_RDROL;
> -
> - err = device_property_read_u32(dev, "size", &val);
> - if (!err)
> - chip->byte_len = val;
> -
> - err = device_property_read_u32(dev, "pagesize", &val);
> - if (!err) {
> - chip->page_size = val;
> - } else {
> - /*
> - * This is slow, but we can't know all eeproms, so we better
> - * play safe. Specifying custom eeprom-types via platform_data
> - * is recommended anyhow.
> - */
> - chip->page_size = 1;
> - }
> -}
> -
> -static int at24_get_pdata(struct device *dev, struct at24_platform_data *pdata)
> +static const struct at24_chip_data *at24_get_chip_data(struct device *dev)
> {
> struct device_node *of_node = dev->of_node;
> const struct at24_chip_data *cdata;
> const struct i2c_device_id *id;
> - struct at24_platform_data *pd;
> -
> - pd = dev_get_platdata(dev);
> - if (pd) {
> - memcpy(pdata, pd, sizeof(*pdata));
> - return 0;
> - }
>
> id = i2c_match_id(at24_ids, to_i2c_client(dev));
>
> @@ -523,13 +498,9 @@ static int at24_get_pdata(struct device *dev, struct at24_platform_data *pdata)
> cdata = acpi_device_get_match_data(dev);
>
> if (!cdata)
> - return -ENODEV;
> + return ERR_PTR(-ENODEV);
>
> - pdata->byte_len = cdata->byte_len;
> - pdata->flags = cdata->flags;
> - at24_properties_to_pdata(dev, pdata);
> -
> - return 0;
> + return cdata;
> }
>
> static void at24_remove_dummy_clients(struct at24_data *at24)
> @@ -598,8 +569,9 @@ static int at24_probe(struct i2c_client *client)
> {
> struct regmap_config regmap_config = { };
> struct nvmem_config nvmem_config = { };
> - struct at24_platform_data pdata = { };
> + const struct at24_chip_data *cdata;
> struct device *dev = &client->dev;
> + u32 byte_len, page_size, flags;
> bool i2c_fn_i2c, i2c_fn_block;
> unsigned int i, num_addresses;
> struct at24_data *at24;
> @@ -613,35 +585,54 @@ static int at24_probe(struct i2c_client *client)
> i2c_fn_block = i2c_check_functionality(client->adapter,
> I2C_FUNC_SMBUS_WRITE_I2C_BLOCK);
>
> - err = at24_get_pdata(dev, &pdata);
> + cdata = at24_get_chip_data(dev);
> + if (IS_ERR(cdata))
> + return PTR_ERR(cdata);
> +
> + err = device_property_read_u32(dev, "pagesize", &page_size);
> + if (err)
> + /*
> + * This is slow, but we can't know all eeproms, so we better
> + * play safe. Specifying custom eeprom-types via platform_data
> + * is recommended anyhow.
> + */
> + page_size = 1;
> +
> + flags = cdata->flags;
> + if (device_property_present(dev, "read-only"))
> + flags |= AT24_FLAG_READONLY;
> + if (device_property_present(dev, "no-read-rollover"))
> + flags |= AT24_FLAG_NO_RDROL;
> +
> + err = device_property_read_u32(dev, "size", &byte_len);
> if (err)
> - return err;
> + byte_len = cdata->byte_len;
>
> if (!i2c_fn_i2c && !i2c_fn_block)
> - pdata.page_size = 1;
> + page_size = 1;
>
> - if (!pdata.page_size) {
> + if (!page_size) {
> dev_err(dev, "page_size must not be 0!\n");
> return -EINVAL;
> }
>
> - if (!is_power_of_2(pdata.page_size))
> + if (!is_power_of_2(page_size))
> dev_warn(dev, "page_size looks suspicious (no power of 2)!\n");
>
> - if (pdata.flags & AT24_FLAG_TAKE8ADDR)
> + if (flags & AT24_FLAG_TAKE8ADDR)
> num_addresses = 8;
> else
> - num_addresses = DIV_ROUND_UP(pdata.byte_len,
> - (pdata.flags & AT24_FLAG_ADDR16) ? 65536 : 256);
> + num_addresses = DIV_ROUND_UP(byte_len,
> + (flags & AT24_FLAG_ADDR16) ? 65536 : 256);
>
> - if ((pdata.flags & AT24_FLAG_SERIAL) && (pdata.flags & AT24_FLAG_MAC)) {
> + if ((flags & AT24_FLAG_SERIAL) && (flags & AT24_FLAG_MAC)) {
> dev_err(dev,
> "invalid device data - cannot have both AT24_FLAG_SERIAL & AT24_FLAG_MAC.");
> return -EINVAL;
> }
>
> regmap_config.val_bits = 8;
> - regmap_config.reg_bits = (pdata.flags & AT24_FLAG_ADDR16) ? 16 : 8;
> + regmap_config.reg_bits = (flags & AT24_FLAG_ADDR16) ? 16 : 8;
> regmap_config.disable_locking = true;
>
> regmap = devm_regmap_init_i2c(client, ®map_config);
> @@ -654,11 +645,11 @@ static int at24_probe(struct i2c_client *client)
> return -ENOMEM;
>
> mutex_init(&at24->lock);
> - at24->byte_len = pdata.byte_len;
> - at24->page_size = pdata.page_size;
> - at24->flags = pdata.flags;
> + at24->byte_len = byte_len;
> + at24->page_size = page_size;
> + at24->flags = flags;
> at24->num_addresses = num_addresses;
> - at24->offset_adj = at24_get_offset_adj(pdata.flags, pdata.byte_len);
> + at24->offset_adj = at24_get_offset_adj(flags, byte_len);
> at24->client[0].client = client;
> at24->client[0].regmap = regmap;
>
> @@ -666,10 +657,10 @@ static int at24_probe(struct i2c_client *client)
> if (IS_ERR(at24->wp_gpio))
> return PTR_ERR(at24->wp_gpio);
>
> - writable = !(pdata.flags & AT24_FLAG_READONLY);
> + writable = !(flags & AT24_FLAG_READONLY);
> if (writable) {
> at24->write_max = min_t(unsigned int,
> - pdata.page_size, at24_io_limit);
> + page_size, at24_io_limit);
> if (!i2c_fn_i2c && at24->write_max > I2C_SMBUS_BLOCK_MAX)
> at24->write_max = I2C_SMBUS_BLOCK_MAX;
> }
> @@ -712,7 +703,7 @@ static int at24_probe(struct i2c_client *client)
> nvmem_config.priv = at24;
> nvmem_config.stride = 1;
> nvmem_config.word_size = 1;
> - nvmem_config.size = pdata.byte_len;
> + nvmem_config.size = byte_len;
>
> at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
> if (IS_ERR(at24->nvmem)) {
> @@ -721,13 +712,9 @@ static int at24_probe(struct i2c_client *client)
> }
>
> dev_info(dev, "%u byte %s EEPROM, %s, %u bytes/write\n",
> - pdata.byte_len, client->name,
> + byte_len, client->name,
> writable ? "writable" : "read-only", at24->write_max);
>
> - /* export data to kernel code */
> - if (pdata.setup)
> - pdata.setup(at24->nvmem, pdata.context);
> -
> return 0;
>
> err_clients:
> diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
> deleted file mode 100644
> index 63507ff464ee..000000000000
> --- a/include/linux/platform_data/at24.h
> +++ /dev/null
> @@ -1,60 +0,0 @@
> -/*
> - * at24.h - platform_data for the at24 (generic eeprom) driver
> - * (C) Copyright 2008 by Pengutronix
> - * (C) Copyright 2012 by Wolfram Sang
> - * same license as the driver
> - */
> -
> -#ifndef _LINUX_AT24_H
> -#define _LINUX_AT24_H
> -
> -#include <linux/types.h>
> -#include <linux/nvmem-consumer.h>
> -#include <linux/bitops.h>
> -
> -/**
> - * struct at24_platform_data - data to set up at24 (generic eeprom) driver
> - * @byte_len: size of eeprom in byte
> - * @page_size: number of byte which can be written in one go
> - * @flags: tunable options, check AT24_FLAG_* defines
> - * @setup: an optional callback invoked after eeprom is probed; enables kernel
> - code to access eeprom via nvmem, see example
> - * @context: optional parameter passed to setup()
> - *
> - * If you set up a custom eeprom type, please double-check the parameters.
> - * Especially page_size needs extra care, as you risk data loss if your value
> - * is bigger than what the chip actually supports!
> - *
> - * An example in pseudo code for a setup() callback:
> - *
> - * void get_mac_addr(struct nvmem_device *nvmem, void *context)
> - * {
> - * u8 *mac_addr = ethernet_pdata->mac_addr;
> - * off_t offset = context;
> - *
> - * // Read MAC addr from EEPROM
> - * if (nvmem_device_read(nvmem, offset, ETH_ALEN, mac_addr) == ETH_ALEN)
> - * pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);
> - * }
> - *
> - * This function pointer and context can now be set up in at24_platform_data.
> - */
> -
> -struct at24_platform_data {
> - u32 byte_len; /* size (sum of all addr) */
> - u16 page_size; /* for writes */
> - u8 flags;
> -#define AT24_FLAG_ADDR16 BIT(7) /* address pointer is 16 bit */
> -#define AT24_FLAG_READONLY BIT(6) /* sysfs-entry will be read-only */
> -#define AT24_FLAG_IRUGO BIT(5) /* sysfs-entry will be world-readable */
> -#define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */
> -#define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */
> -#define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */
> -#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */
> - /* the next slave address */
> -
> - void (*setup)(struct nvmem_device *nvmem, void *context);
> - void *context;
> -};
> -
> -#endif /* _LINUX_AT24_H */
> --
> 2.18.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net-next v2 0/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-08 23:26 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
This patch does a combined memory allocation from heap for scatterlists,
aead_request, aad and iv for the tls record decryption path. In present
code, aead_request is allocated from heap, scatterlists on a conditional
basis are allocated on heap or on stack. This is inefficient as it may
requires multiple kmalloc/kfree.
The initialization vector passed in cryption request is allocated on
stack. This is a problem since the stack memory is not dma-able from
crypto accelerators.
Doing one combined memory allocation for each decryption request fixes
both the above issues. It also paves a way to be able to submit multiple
async decryption requests while the previous one is pending i.e. being
processed or queued.
This patch needs to be applied over Doron Roberts-Kedes's patch.
net/tls: Calculate nsg for zerocopy path without skb_cow_data.
Vakul Garg (1):
net/tls: Combined memory allocation for decryption request
include/net/tls.h | 4 -
net/tls/tls_sw.c | 257 ++++++++++++++++++++++++++++++------------------------
2 files changed, 145 insertions(+), 116 deletions(-)
--
2.13.6
^ permalink raw reply
* [PATCH net-next v2 1/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-08 23:26 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
In-Reply-To: <20180808232623.18075-1-vakul.garg@nxp.com>
For preparing decryption request, several memory chunks are required
(aead_req, sgin, sgout, iv, aad). For submitting the decrypt request to
an accelerator, it is required that the buffers which are read by the
accelerator must be dma-able and not come from stack. The buffers for
aad and iv can be separately kmalloced each, but it is inefficient.
This patch does a combined allocation for preparing decryption request
and then segments into aead_req || sgin || sgout || iv || aad.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
This patch needs to be applied over Doron Roberts-Kedes's patch.
net/tls: Calculate nsg for zerocopy path without skb_cow_data.
Changes since patch v1:
- Removed unused label 'no_zerocopy'
include/net/tls.h | 4 -
net/tls/tls_sw.c | 257 ++++++++++++++++++++++++++++++------------------------
2 files changed, 145 insertions(+), 116 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index d8b3b6578c01..d5c683e8bb22 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -124,10 +124,6 @@ struct tls_sw_context_rx {
struct sk_buff *recv_pkt;
u8 control;
bool decrypted;
-
- char rx_aad_ciphertext[TLS_AAD_SPACE_SIZE];
- char rx_aad_plaintext[TLS_AAD_SPACE_SIZE];
-
};
struct tls_record_info {
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 55eb04415bb3..13e365011347 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -122,19 +122,13 @@ static int tls_do_decryption(struct sock *sk,
struct scatterlist *sgout,
char *iv_recv,
size_t data_len,
- struct sk_buff *skb,
- gfp_t flags)
+ struct aead_request *aead_req)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
- struct aead_request *aead_req;
-
int ret;
- aead_req = aead_request_alloc(ctx->aead_recv, flags);
- if (!aead_req)
- return -ENOMEM;
-
+ aead_request_set_tfm(aead_req, ctx->aead_recv);
aead_request_set_ad(aead_req, TLS_AAD_SPACE_SIZE);
aead_request_set_crypt(aead_req, sgin, sgout,
data_len + tls_ctx->rx.tag_size,
@@ -143,8 +137,6 @@ static int tls_do_decryption(struct sock *sk,
crypto_req_done, &ctx->async_wait);
ret = crypto_wait_req(crypto_aead_decrypt(aead_req), &ctx->async_wait);
-
- aead_request_free(aead_req);
return ret;
}
@@ -731,8 +723,135 @@ static struct sk_buff *tls_wait_data(struct sock *sk, int flags,
return skb;
}
+/* This function decrypts the input skb into either out_iov or in out_sg
+ * or in skb buffers itself. The input parameter 'zc' indicates if
+ * zero-copy mode needs to be tried or not. With zero-copy mode, either
+ * out_iov or out_sg must be non-NULL. In case both out_iov and out_sg are
+ * NULL, then the decryption happens inside skb buffers itself, i.e.
+ * zero-copy gets disabled and 'zc' is updated.
+ */
+
+static int decrypt_internal(struct sock *sk, struct sk_buff *skb,
+ struct iov_iter *out_iov,
+ struct scatterlist *out_sg,
+ int *chunk, bool *zc)
+{
+ struct tls_context *tls_ctx = tls_get_ctx(sk);
+ struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
+ struct strp_msg *rxm = strp_msg(skb);
+ int n_sgin, n_sgout, nsg, mem_size, aead_size, err, pages = 0;
+ struct aead_request *aead_req;
+ struct sk_buff *unused;
+ u8 *aad, *iv, *mem = NULL;
+ struct scatterlist *sgin = NULL;
+ struct scatterlist *sgout = NULL;
+ const int data_len = rxm->full_len - tls_ctx->rx.overhead_size;
+
+ if (*zc && (out_iov || out_sg)) {
+ if (out_iov)
+ n_sgout = iov_iter_npages(out_iov, INT_MAX) + 1;
+ else
+ n_sgout = sg_nents(out_sg);
+
+ n_sgin = skb_nsg(skb, rxm->offset + tls_ctx->rx.prepend_size,
+ rxm->full_len - tls_ctx->rx.prepend_size);
+ } else {
+ n_sgout = 0;
+ *zc = false;
+ n_sgin = skb_cow_data(skb, 0, &unused);
+ }
+
+ if (n_sgin < 1)
+ return -EBADMSG;
+
+ /* Increment to accommodate AAD */
+ n_sgin = n_sgin + 1;
+
+ nsg = n_sgin + n_sgout;
+
+ aead_size = sizeof(*aead_req) + crypto_aead_reqsize(ctx->aead_recv);
+ mem_size = aead_size + (nsg * sizeof(struct scatterlist));
+ mem_size = mem_size + TLS_AAD_SPACE_SIZE;
+ mem_size = mem_size + crypto_aead_ivsize(ctx->aead_recv);
+
+ /* Allocate a single block of memory which contains
+ * aead_req || sgin[] || sgout[] || aad || iv.
+ * This order achieves correct alignment for aead_req, sgin, sgout.
+ */
+ mem = kmalloc(mem_size, sk->sk_allocation);
+ if (!mem)
+ return -ENOMEM;
+
+ /* Segment the allocated memory */
+ aead_req = (struct aead_request *)mem;
+ sgin = (struct scatterlist *)(mem + aead_size);
+ sgout = sgin + n_sgin;
+ aad = (u8 *)(sgout + n_sgout);
+ iv = aad + TLS_AAD_SPACE_SIZE;
+
+ /* Prepare IV */
+ err = skb_copy_bits(skb, rxm->offset + TLS_HEADER_SIZE,
+ iv + TLS_CIPHER_AES_GCM_128_SALT_SIZE,
+ tls_ctx->rx.iv_size);
+ if (err < 0) {
+ kfree(mem);
+ return err;
+ }
+ memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
+
+ /* Prepare AAD */
+ tls_make_aad(aad, rxm->full_len - tls_ctx->rx.overhead_size,
+ tls_ctx->rx.rec_seq, tls_ctx->rx.rec_seq_size,
+ ctx->control);
+
+ /* Prepare sgin */
+ sg_init_table(sgin, n_sgin);
+ sg_set_buf(&sgin[0], aad, TLS_AAD_SPACE_SIZE);
+ err = skb_to_sgvec(skb, &sgin[1],
+ rxm->offset + tls_ctx->rx.prepend_size,
+ rxm->full_len - tls_ctx->rx.prepend_size);
+ if (err < 0) {
+ kfree(mem);
+ return err;
+ }
+
+ if (n_sgout) {
+ if (out_iov) {
+ sg_init_table(sgout, n_sgout);
+ sg_set_buf(&sgout[0], aad, TLS_AAD_SPACE_SIZE);
+
+ *chunk = 0;
+ err = zerocopy_from_iter(sk, out_iov, data_len, &pages,
+ chunk, &sgout[1],
+ (n_sgout - 1), false);
+ if (err < 0)
+ goto fallback_to_reg_recv;
+ } else if (out_sg) {
+ memcpy(sgout, out_sg, n_sgout * sizeof(*sgout));
+ } else {
+ goto fallback_to_reg_recv;
+ }
+ } else {
+fallback_to_reg_recv:
+ sgout = sgin;
+ pages = 0;
+ *chunk = 0;
+ *zc = false;
+ }
+
+ /* Prepare and submit AEAD request */
+ err = tls_do_decryption(sk, sgin, sgout, iv, data_len, aead_req);
+
+ /* Release the pages in case iov was mapped to pages */
+ for (; pages > 0; pages--)
+ put_page(sg_page(&sgout[pages]));
+
+ kfree(mem);
+ return err;
+}
+
static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
- struct scatterlist *sgout, bool *zc)
+ struct iov_iter *dest, int *chunk, bool *zc)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
@@ -745,7 +864,7 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
return err;
#endif
if (!ctx->decrypted) {
- err = decrypt_skb(sk, skb, sgout);
+ err = decrypt_internal(sk, skb, dest, NULL, chunk, zc);
if (err < 0)
return err;
} else {
@@ -764,70 +883,10 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
int decrypt_skb(struct sock *sk, struct sk_buff *skb,
struct scatterlist *sgout)
{
- struct tls_context *tls_ctx = tls_get_ctx(sk);
- struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
- char iv[TLS_CIPHER_AES_GCM_128_SALT_SIZE + MAX_IV_SIZE];
- struct scatterlist sgin_arr[MAX_SKB_FRAGS + 2];
- struct scatterlist *sgin = &sgin_arr[0];
- struct strp_msg *rxm = strp_msg(skb);
- int ret, nsg;
- struct sk_buff *unused;
-
- ret = skb_copy_bits(skb, rxm->offset + TLS_HEADER_SIZE,
- iv + TLS_CIPHER_AES_GCM_128_SALT_SIZE,
- tls_ctx->rx.iv_size);
- if (ret < 0)
- return ret;
-
- memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
- if (!sgout) {
- nsg = skb_cow_data(skb, 0, &unused);
- } else {
- nsg = skb_nsg(skb,
- rxm->offset + tls_ctx->rx.prepend_size,
- rxm->full_len - tls_ctx->rx.prepend_size);
- if (nsg <= 0)
- return nsg;
- }
-
- // We need one extra for ctx->rx_aad_ciphertext
- nsg++;
-
- if (nsg > ARRAY_SIZE(sgin_arr)) {
- sgin = kmalloc_array(nsg, sizeof(*sgin), sk->sk_allocation);
- if (!sgin)
- return -ENOMEM;
- }
-
- if (!sgout)
- sgout = sgin;
-
- sg_init_table(sgin, nsg);
- sg_set_buf(&sgin[0], ctx->rx_aad_ciphertext, TLS_AAD_SPACE_SIZE);
-
- nsg = skb_to_sgvec(skb, &sgin[1],
- rxm->offset + tls_ctx->rx.prepend_size,
- rxm->full_len - tls_ctx->rx.prepend_size);
- if (nsg < 0) {
- ret = nsg;
- goto out;
- }
-
- tls_make_aad(ctx->rx_aad_ciphertext,
- rxm->full_len - tls_ctx->rx.overhead_size,
- tls_ctx->rx.rec_seq,
- tls_ctx->rx.rec_seq_size,
- ctx->control);
-
- ret = tls_do_decryption(sk, sgin, sgout, iv,
- rxm->full_len - tls_ctx->rx.overhead_size,
- skb, sk->sk_allocation);
-
-out:
- if (sgin != &sgin_arr[0])
- kfree(sgin);
+ bool zc = true;
+ int chunk;
- return ret;
+ return decrypt_internal(sk, skb, NULL, sgout, &chunk, &zc);
}
static bool tls_sw_advance_skb(struct sock *sk, struct sk_buff *skb,
@@ -906,43 +965,17 @@ int tls_sw_recvmsg(struct sock *sk,
}
if (!ctx->decrypted) {
- int page_count;
- int to_copy;
-
- page_count = iov_iter_npages(&msg->msg_iter,
- MAX_SKB_FRAGS);
- to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
- if (!is_kvec && to_copy <= len && page_count < MAX_SKB_FRAGS &&
- likely(!(flags & MSG_PEEK))) {
- struct scatterlist sgin[MAX_SKB_FRAGS + 1];
- int pages = 0;
+ int to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
+ if (!is_kvec && to_copy <= len &&
+ likely(!(flags & MSG_PEEK)))
zc = true;
- sg_init_table(sgin, MAX_SKB_FRAGS + 1);
- sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
- TLS_AAD_SPACE_SIZE);
-
- err = zerocopy_from_iter(sk, &msg->msg_iter,
- to_copy, &pages,
- &chunk, &sgin[1],
- MAX_SKB_FRAGS, false);
- if (err < 0)
- goto fallback_to_reg_recv;
-
- err = decrypt_skb_update(sk, skb, sgin, &zc);
- for (; pages > 0; pages--)
- put_page(sg_page(&sgin[pages]));
- if (err < 0) {
- tls_err_abort(sk, EBADMSG);
- goto recv_end;
- }
- } else {
-fallback_to_reg_recv:
- err = decrypt_skb_update(sk, skb, NULL, &zc);
- if (err < 0) {
- tls_err_abort(sk, EBADMSG);
- goto recv_end;
- }
+
+ err = decrypt_skb_update(sk, skb, &msg->msg_iter,
+ &chunk, &zc);
+ if (err < 0) {
+ tls_err_abort(sk, EBADMSG);
+ goto recv_end;
}
ctx->decrypted = true;
}
@@ -993,7 +1026,7 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
int err = 0;
long timeo;
int chunk;
- bool zc;
+ bool zc = false;
lock_sock(sk);
@@ -1010,7 +1043,7 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
}
if (!ctx->decrypted) {
- err = decrypt_skb_update(sk, skb, NULL, &zc);
+ err = decrypt_skb_update(sk, skb, NULL, &chunk, &zc);
if (err < 0) {
tls_err_abort(sk, EBADMSG);
--
2.13.6
^ permalink raw reply related
* RE: [PATCH net-next v1 1/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-08 18:08 UTC (permalink / raw)
To: Dave Watson
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davem@davemloft.net
In-Reply-To: <20180808170716.GB82808@davejwatson-mba.local>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Wednesday, August 8, 2018 10:37 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davem@davemloft.net
> Subject: Re: [PATCH net-next v1 1/1] net/tls: Combined memory allocation
> for decryption request
>
> On 08/08/18 06:36 PM, Vakul Garg wrote:
> > For preparing decryption request, several memory chunks are required
> > (aead_req, sgin, sgout, iv, aad). For submitting the decrypt request
> > to an accelerator, it is required that the buffers which are read by
> > the accelerator must be dma-able and not come from stack. The buffers
> > for aad and iv can be separately kmalloced each, but it is inefficient.
> > This patch does a combined allocation for preparing decryption request
> > and then segments into aead_req || sgin || sgout || iv || aad.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> > ---
> > + n_sgout = sg_nents(out_sg);
> > +
> > + n_sgin = skb_nsg(skb, rxm->offset + tls_ctx->rx.prepend_size,
> > + rxm->full_len - tls_ctx->rx.prepend_size);
> > + } else {
> > +no_zerocopy:
>
> label is unused now
Thanks for reviewing the patch.
I wish compiler could have warned about unused label..
I have submitted 'v2'.
^ permalink raw reply
* Re: [RFC net-next 00/15] net: A socket API for LoRa
From: Alan Cox @ 2018-08-08 20:36 UTC (permalink / raw)
To: Andreas Färber
Cc: Michal Kubeček, Konstantin Böhm, Pieter Robyns, contact,
Ken Yu, Michael Röder, Stefan Schmidt, Rob Herring, lora,
Alexander Graf, Jan Jongboom, Janus Piwek, Jon Ortego,
Jian-Hong Pan, devicetree, Jiri Pirko, Hasnain Virk,
Daniele Comel, Marcel Holtmann, Mark Brown, Dollar Chen,
Brian Ray, linux-arm-kernel
In-Reply-To: <92ee4016-1da9-826b-3674-b2d604a64848@suse.de>
On Sun, 5 Aug 2018 02:11:25 +0200
Andreas Färber <afaerber@suse.de> wrote:
> Hi Jian-Hong,
>
> Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan:
> > 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>:
> >> 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode
> >> would be DGRAM plus preamble plus optional checksum.
> >
> > Is the preamble added by the hardware itself here or software here?
>
> That depends on the driver. For SX127x and any SX127x based modules it
> is added by hardware and a SOCK_RAW seems impossible. If you were to use
> some SDR hardware, it would need to be done by software and might either
> be done in the device driver for SOCK_DGRAM or by user with a SOCK_RAW.
> Right now I don't see a practical use case for the latter. (CC Pieter)
For TCP/IP a SOCK_RAW is a socket with raw IP level access. It doesn't
deal in IP headers and unless you ask it also does chunks of IP header
stuff for you.
SOCK_PACKET is the truely raw interface and even then it's rawness is
bounded. You can't for example talk truely raw wifi bit streams, and for
ethernet you get to generate MAC headers but not preambles etc.
> LoRa radio channels being half-duplex, we'd need to stop receiving in
> ndo_start_xmit and re-start receiving in the TX interrupt handler AFAIU.
> Yes, it's ugly - one reason I haven't implemented RX in sx1276 yet.
Why - the signal is still floating around in the air, you can't unhear it
at the antenna. If a given piece of hardware needs to flip between RX
and TX mode then it should be handled by that driver.
(Some ancient ethernet cards do this btw.. they can't listen and transmit
at the same time)
> > - We can have a pre-defined table according to LoRaWAN Regional Parameters.
> > - Device driver declares the hardware's capability, for example
> > frequency, TX power. And then registers as a LoRaWAN compatible
> > device.
>
> That sounds like a layering violation. We rather need to expose all
> these tunable parameters individually at the LoRa layer, allowing the
> LoRaWAN layer to configure them as it pleases. Not the other direction.
> That still leaves my above question 4) open of how to implement each.
Wifi already has the general policy database for the various existing
protocols. Please take a look at the CRDA agent and how it hooks into
wireless.It might need to some tweaking but it would be odd to have
different configuration schemes for different wifi protocols.
> The use case I have in mind is this: User A opens a LoRaWAN socket and
> using maclorawan sends a packet P1. Here the LoRaWAN Regional Parameters
> and LoRaWAN Sync Word need to be applied.
> User B then opens a pure LoRa socket and transmits a packet P1' with
> different Sync Word, SF, BW, CR, etc.
> Afterwards user A wants to send another packet P2 via LoRaWAN - this
> needs to use the same LoRaWAN settings as before, not those used for
> LoRa in between. Therefore I was thinking about socket-level options, as
> netlink operations would be device-wide, with undesired side-effects.
Agreed
> Obviously in that scenario not both users can receive at the same time.
That's a hardware question. Imagine a software defined radio. If your
limitation wouldn't exist in a pure software defined radio then it's
almost certainly a device level detal.
> interface but cleanly distinguished as ETH_P_GFSK or something.
> For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module.
Agreed if you can flip per packet.
> The next question arising is how the user would create such an skb. Just
> like I was hesitant about PF_LORAWAN originally, I'd like to avoid
> polluting the PF_ number space for each of these. Maybe have one PF_FSK
> as equivalent to PF_LORA and then have either a socket option or
> sockaddr field to select the modulation variants? Not sure how exactly
> those others differ from each other, that's why I tried to postpone the
> FSK topic and to focus on LoRa first - b) below.
>
> At this point we could also argue whether we need a PF_LORA at all or
> rather just some generic PF_RADIO with lots of options stored in its
> sockaddr.
What matters most is mux/demux.
If you've got something listening to data but without the structure
needed to identify multiple listeners and split out the data meaningfully
to those listeners according to parts of the packet then you've got no
reason to make it a protocol just use SOCK_PACKET and if need be BPF.
The reason we have a socket layer not /dev/ethernet0 is that it's
meaningful to divide messages up into flows, and to partition those flows
securely amongst multiple consumers/generators.
Alan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH ethtool 0/3] ethtool: Wake-on-LAN using filters
From: Florian Fainelli @ 2018-08-08 18:22 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem, Florian Fainelli
Hi John,
This patch series syncs up ethtool-copy.h to get the new definitions
required for supporting wake-on-LAN using filters: WAKE_FILTER and
RX_CLS_FLOW_WAKE and then updates the rxclass.c code to allow us to
specify action -2 (RX_CLS_FLOW_WAKE).
Let me know if you would like this to be done differently.
Thanks!
Florian Fainelli (3):
ethtool-copy.h: sync with net-next
ethtool: Add support for WAKE_FILTER (WoL using filters)
ethtool: Add support for action value -2 (wake-up filter)
ethtool-copy.h | 15 +++++++++++----
ethtool.8.in | 4 +++-
ethtool.c | 5 +++++
rxclass.c | 8 +++++---
4 files changed, 24 insertions(+), 8 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH ethtool 1/3] ethtool-copy.h: sync with net-next
From: Florian Fainelli @ 2018-08-08 18:22 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem, Florian Fainelli
In-Reply-To: <20180808182211.24921-1-f.fainelli@gmail.com>
This covers kernel changes up to commit 6cfef793b558:
ethtool: Add WAKE_FILTER and RX_CLS_FLOW_WAKE
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
ethtool-copy.h | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 8cc61e9ab40b..6bfbb85f9402 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -215,12 +215,16 @@ struct ethtool_value {
__u32 data;
};
+#define PFC_STORM_PREVENTION_AUTO 0xffff
+#define PFC_STORM_PREVENTION_DISABLE 0
+
enum tunable_id {
ETHTOOL_ID_UNSPEC,
ETHTOOL_RX_COPYBREAK,
ETHTOOL_TX_COPYBREAK,
+ ETHTOOL_PFC_PREVENTION_TOUT, /* timeout in msecs */
/*
- * Add your fresh new tubale attribute above and remember to update
+ * Add your fresh new tunable attribute above and remember to update
* tunable_strings[] in net/core/ethtool.c
*/
__ETHTOOL_TUNABLE_COUNT,
@@ -864,7 +868,8 @@ struct ethtool_flow_ext {
* includes the %FLOW_EXT or %FLOW_MAC_EXT flag
* (see &struct ethtool_flow_ext description).
* @ring_cookie: RX ring/queue index to deliver to, or %RX_CLS_FLOW_DISC
- * if packets should be discarded
+ * if packets should be discarded, or %RX_CLS_FLOW_WAKE if the
+ * packets should be used for Wake-on-LAN with %WAKE_FILTER
* @location: Location of rule in the table. Locations must be
* numbered such that a flow matching multiple rules will be
* classified according to the first (lowest numbered) rule.
@@ -896,13 +901,13 @@ struct ethtool_rx_flow_spec {
static __inline__ __u64 ethtool_get_flow_spec_ring(__u64 ring_cookie)
{
return ETHTOOL_RX_FLOW_SPEC_RING & ring_cookie;
-};
+}
static __inline__ __u64 ethtool_get_flow_spec_ring_vf(__u64 ring_cookie)
{
return (ETHTOOL_RX_FLOW_SPEC_RING_VF & ring_cookie) >>
ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
-};
+}
/**
* struct ethtool_rxnfc - command to get or set RX flow classification rules
@@ -1628,6 +1633,7 @@ static __inline__ int ethtool_validate_duplex(__u8 duplex)
#define WAKE_ARP (1 << 4)
#define WAKE_MAGIC (1 << 5)
#define WAKE_MAGICSECURE (1 << 6) /* only meaningful if WAKE_MAGIC */
+#define WAKE_FILTER (1 << 7)
/* L2-L4 network traffic flow types */
#define TCP_V4_FLOW 0x01 /* hash or spec (tcp_ip4_spec) */
@@ -1665,6 +1671,7 @@ static __inline__ int ethtool_validate_duplex(__u8 duplex)
#define RXH_DISCARD (1 << 31)
#define RX_CLS_FLOW_DISC 0xffffffffffffffffULL
+#define RX_CLS_FLOW_WAKE 0xfffffffffffffffeULL
/* Special RX classification rule insert location values */
#define RX_CLS_LOC_SPECIAL 0x80000000 /* flag */
--
2.17.1
^ permalink raw reply related
* [PATCH ethtool 2/3] ethtool: Add support for WAKE_FILTER (WoL using filters)
From: Florian Fainelli @ 2018-08-08 18:22 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem, Florian Fainelli
In-Reply-To: <20180808182211.24921-1-f.fainelli@gmail.com>
Add a new character 'f' which can be used to configure an Ethernet
controller to support Wake-on-LAN using filters programmed with the
ethtool::rxnfc and the special action -2 (wake-up filter). This is
useful in particular in the context of devices that must support wake-up
on more complex patterns such as multicast DNS packets.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
ethtool.8.in | 4 +++-
ethtool.c | 5 +++++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/ethtool.8.in b/ethtool.8.in
index 0a366aa536ae..97c7330fd373 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -58,7 +58,7 @@
.\"
.\" \(*WO - wol flags
.\"
-.ds WO \fBp\fP|\fBu\fP|\fBm\fP|\fBb\fP|\fBa\fP|\fBg\fP|\fBs\fP|\fBd\fP...
+.ds WO \fBp\fP|\fBu\fP|\fBm\fP|\fBb\fP|\fBa\fP|\fBg\fP|\fBs\fP|\fBf|\fBd\fP...
.\"
.\" \(*FL - flow type values
.\"
@@ -679,6 +679,7 @@ b Wake on broadcast messages
a Wake on ARP
g Wake on MagicPacket\[tm]
s Enable SecureOn\[tm] password for MagicPacket\[tm]
+f Wake on filter(s)
d T{
Disable (wake on nothing). This option clears all previous options.
T}
@@ -870,6 +871,7 @@ Specifies the Rx queue to send packets to, or some other action.
nokeep;
lB l.
-1 Drop the matched flow
+-2 Use the matched flow as a Wake-on-LAN filter
0 or higher Rx queue to route the flow
.TE
.TP
diff --git a/ethtool.c b/ethtool.c
index fb93ae898312..aa2bbe9e4c65 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -931,6 +931,9 @@ static int parse_wolopts(char *optstr, u32 *data)
case 's':
*data |= WAKE_MAGICSECURE;
break;
+ case 'f':
+ *data |= WAKE_FILTER;
+ break;
case 'd':
*data = 0;
break;
@@ -964,6 +967,8 @@ static char *unparse_wolopts(int wolopts)
*p++ = 'g';
if (wolopts & WAKE_MAGICSECURE)
*p++ = 's';
+ if (wolopts & WAKE_FILTER)
+ *p++ = 'f';
} else {
*p = 'd';
}
--
2.17.1
^ permalink raw reply related
* [PATCH ethtool 3/3] ethtool: Add support for action value -2 (wake-up filter)
From: Florian Fainelli @ 2018-08-08 18:22 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem, Florian Fainelli
In-Reply-To: <20180808182211.24921-1-f.fainelli@gmail.com>
Add the ability to program special filters using ethtool::rxnfc which
are meant to be used for wake-up purposes (in conjuction with
WAKE_FILTER) using the special action value: -2 (RX_CLS_FLOW_WAKE).
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
rxclass.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/rxclass.c b/rxclass.c
index 42d122d1ed86..79972651e706 100644
--- a/rxclass.c
+++ b/rxclass.c
@@ -251,7 +251,11 @@ static void rxclass_print_nfc_rule(struct ethtool_rx_flow_spec *fsp,
if (fsp->flow_type & FLOW_RSS)
fprintf(stdout, "\tRSS Context ID: %u\n", rss_context);
- if (fsp->ring_cookie != RX_CLS_FLOW_DISC) {
+ if (fsp->ring_cookie == RX_CLS_FLOW_DISC) {
+ fprintf(stdout, "\tAction: Drop\n");
+ } else if (fsp->ring_cookie == RX_CLS_FLOW_WAKE) {
+ fprintf(stdout, "\tAction: Wake-on-LAN\n");
+ } else {
u64 vf = ethtool_get_flow_spec_ring_vf(fsp->ring_cookie);
u64 queue = ethtool_get_flow_spec_ring(fsp->ring_cookie);
@@ -266,8 +270,6 @@ static void rxclass_print_nfc_rule(struct ethtool_rx_flow_spec *fsp,
else
fprintf(stdout, "\tAction: Direct to queue %llu\n",
queue);
- } else {
- fprintf(stdout, "\tAction: Drop\n");
}
fprintf(stdout, "\n");
--
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