* Re: [PATCH 1/2] xsk: do not use mmap_sem
From: Daniel Borkmann @ 2019-02-11 15:33 UTC (permalink / raw)
To: Björn Töpel, Davidlohr Bueso
Cc: akpm, linux-mm, LKML, David S . Miller, Bjorn Topel,
Magnus Karlsson, Netdev, Davidlohr Bueso, dan.j.williams
In-Reply-To: <CAJ+HfNg=Wikc_uY9W1QiVCONq3c1GyS44-xbrq-J4gqfth2kwQ@mail.gmail.com>
[ +Dan ]
On 02/07/2019 08:43 AM, Björn Töpel wrote:
> Den tors 7 feb. 2019 kl 06:38 skrev Davidlohr Bueso <dave@stgolabs.net>:
>>
>> Holding mmap_sem exclusively for a gup() is an overkill.
>> Lets replace the call for gup_fast() and let the mm take
>> it if necessary.
>>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Bjorn Topel <bjorn.topel@intel.com>
>> Cc: Magnus Karlsson <magnus.karlsson@intel.com>
>> CC: netdev@vger.kernel.org
>> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
>> ---
>> net/xdp/xdp_umem.c | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
>> index 5ab236c5c9a5..25e1e76654a8 100644
>> --- a/net/xdp/xdp_umem.c
>> +++ b/net/xdp/xdp_umem.c
>> @@ -265,10 +265,8 @@ static int xdp_umem_pin_pages(struct xdp_umem *umem)
>> if (!umem->pgs)
>> return -ENOMEM;
>>
>> - down_write(¤t->mm->mmap_sem);
>> - npgs = get_user_pages(umem->address, umem->npgs,
>> - gup_flags, &umem->pgs[0], NULL);
>> - up_write(¤t->mm->mmap_sem);
>> + npgs = get_user_pages_fast(umem->address, umem->npgs,
>> + gup_flags, &umem->pgs[0]);
>>
>
> Thanks for the patch!
>
> The lifetime of the pinning is similar to RDMA umem mapping, so isn't
> gup_longterm preferred?
Seems reasonable from reading what gup_longterm seems to do. Davidlohr
or Dan, any thoughts on the above?
Thanks,
Daniel
^ permalink raw reply
* [PATCH] net: phylink: avoid resolving link state too early
From: Russell King @ 2019-02-11 15:04 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit; +Cc: David S. Miller, netdev
During testing on Armada 388 platforms, it was found with a certain
module configuration that it was possible to trigger a kernel oops
during the module load process, caused by the phylink resolver being
triggered for a currently disabled interface.
This problem was introduced by changing the way the SFP registration
works, which now can result in the sfp link down notification being
called during phylink_create().
Fixes: b5bfc21af5cb ("net: sfp: do not probe SFP module before we're attached")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/phylink.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index e7becc7379d7..938803237d7f 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -474,6 +474,17 @@ static void phylink_run_resolve(struct phylink *pl)
queue_work(system_power_efficient_wq, &pl->resolve);
}
+static void phylink_run_resolve_and_disable(struct phylink *pl, int bit)
+{
+ unsigned long state = pl->phylink_disable_state;
+
+ set_bit(bit, &pl->phylink_disable_state);
+ if (state == 0) {
+ queue_work(system_power_efficient_wq, &pl->resolve);
+ flush_work(&pl->resolve);
+ }
+}
+
static void phylink_fixed_poll(struct timer_list *t)
{
struct phylink *pl = container_of(t, struct phylink, link_poll);
@@ -924,9 +935,7 @@ void phylink_stop(struct phylink *pl)
if (pl->link_an_mode == MLO_AN_FIXED && !IS_ERR(pl->link_gpio))
del_timer_sync(&pl->link_poll);
- set_bit(PHYLINK_DISABLE_STOPPED, &pl->phylink_disable_state);
- queue_work(system_power_efficient_wq, &pl->resolve);
- flush_work(&pl->resolve);
+ phylink_run_resolve_and_disable(pl, PHYLINK_DISABLE_STOPPED);
}
EXPORT_SYMBOL_GPL(phylink_stop);
@@ -1632,9 +1641,7 @@ static void phylink_sfp_link_down(void *upstream)
ASSERT_RTNL();
- set_bit(PHYLINK_DISABLE_LINK, &pl->phylink_disable_state);
- queue_work(system_power_efficient_wq, &pl->resolve);
- flush_work(&pl->resolve);
+ phylink_run_resolve_and_disable(pl, PHYLINK_DISABLE_LINK);
}
static void phylink_sfp_link_up(void *upstream)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length
From: Neil Horman @ 2019-02-11 15:04 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: David Miller, julien, netdev, linux-sctp, linux-kernel, vyasevich,
lucien.xin
In-Reply-To: <20190210124616.GG13621@localhost.localdomain>
On Sun, Feb 10, 2019 at 10:46:16AM -0200, Marcelo Ricardo Leitner wrote:
> On Sat, Feb 09, 2019 at 03:12:17PM -0800, David Miller wrote:
> > From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > Date: Wed, 6 Feb 2019 18:37:54 -0200
> >
> > > On Wed, Feb 06, 2019 at 12:14:30PM -0800, Julien Gomes wrote:
> > >> Make sctp_setsockopt_events() able to accept sctp_event_subscribe
> > >> structures longer than the current definitions.
> > >>
> > >> This should prevent unjustified setsockopt() failures due to struct
> > >> sctp_event_subscribe extensions (as in 4.11 and 4.12) when using
> > >> binaries that should be compatible, but were built with later kernel
> > >> uapi headers.
> > >
> > > Not sure if we support backwards compatibility like this?
> >
> > What a complete mess we have here.
> >
> > Use new socket option numbers next time, do not change the size and/or
> > layout of existing socket options.
>
> What about reusing the same socket option, but defining a new struct?
> Say, MYSOCKOPT supports struct mysockopt, struct mysockopt2, struct
> mysockopt3...
>
> That way we have a clear definition of the user's intent.
>
Thats possible, but I think thats pretty equivalaent to what daves saying, in
that he wants us to identify all the sizes of this struct and the git history
and act on them accordingly. Having internal versions of the struct seems like
a fine way to get there, but I think we need to consider how we got to this
situations before we go down the implementation path.
> >
> > This whole thread, if you read it, is basically "if we compatability
> > this way, that breaks, and if we do compatability this other way oh
> > shit this other thing doesn't work."
> >
> > I think we really need to specifically check for the difference sizes
> > that existed one by one, clear out the part not given by the user, and
> > backport this as far back as possible in a way that in the older kernels
> > we see if the user is actually trying to use the new features and if so
> > error out.
>
> I'm afraid clearing out may not be enough, though seems it's the best
> we can do so far. If the struct is allocated but not fully initialized
> via a memset, but by setting its fields one by one, the remaining new
> fields will be left uninitinialized.
>
I'm not sure this even makes sense. Currently (as I understood it), the issue
we are facing is the one in which an application is built against a newer kernel
and run on an older one, the implication there being that the application will
pass in a buffer that is larger than what the kernel expects. In that
situation, clearing isn't needed, all thats needed (I think), is a memcmp of the
space between the sizeof(kernel struct version), and sizeof(userspace struct
version) to see if any bits are non-zero. If they are, we error out, otherwise,
we ignore the space and move forward as though that overage doesn't exist.
Mind you, I'm not (yet) advocating for that approach, just trying to clarify
whats needed.
> >
> > Which, btw, is terrible behavior. Newly compiled apps should work on
> > older kernels if they don't try to use the new features, and if they
>
> One use case here is: a given distro is using kernel X and app Foo is
> built against it. Then upgrades to X+1, Foo is patched to fix an issue
> and is rebuilt against X+1. The user upgrades Foo package but for
> whatever reason, doesn't upgrade kernel or reboot the system. Here,
> Foo doesn't work anymore until the new kernel is also running.
>
Yes, thats the use case that we're trying to address.
> > can the ones that want to try to use the new features should be able
> > to fall back when that feature isn't available in a non-ambiguous
> > and precisely defined way.
> >
> > The fact that the use of the new feature is hidden in the new
> > structure elements is really rotten.
> >
> > This patch, at best, needs some work and definitely a longer and more
> > detailed commit message.
>
FWIW, before we decide on a course of action, I think I need to point out that,
over the last 10 years, we've extended this structure 6 times, in the following
commits:
0f3fffd8ab1db
7e8616d8e7731
e1cdd553d482c
35ea82d611da5
c95129d127c6d
b444153fb5a64
The first two I believe were modifications during a period when sctp was
actually getting integrated to the kernel, but the last 4 were definately done
during more recent development periods and wen't in without any commentary about
the impact to UAPI compatibility. The check for optlen > sizeof(struct
sctp_event_subscribe) was made back in 2008, and while not spelled out, seems
pretty clearly directed at enforcing compatibility with older appliations, not
compatibility with newer applications running on older kernels.
I really worry about situations in which we need to support applications
expecting features that the running kernel doesn't have. In this particular
situation it seems like a fixable thing, but I could envision situations in
which we just can't do it, and I don't want to set that expectation when we
can't consistently meet it.
So, if the consensus is that we need to support applications built on newer
kernels, but run on older kernels (and I'd like to get verbal consensus on
that), then we need to identify a method to fix this. I'm still hesitant to
do anything that involves us accepting any size buffer over the kernel expected
size, as that puts us in a position to have to read large amounts of user data
(i.e. possible DOS), and just picking an arbitrary large number to limit the
buffer size seems wrong. What if, on receipt of a structure from a newer kernel
(implying a size larger than what the kernel expects), we clamp optlen to the
kernel size, and put_user it back to the application? i.e. we don't check any
data above and beyond what the the kernel knows about, but we use the optlen as
an indicator to user space that not all the data was processed? That allows the
kernel to ignore the overage safely, and while its not in the socket api
extension RFC, its not violating anything, and is something we can document in
the sctp(7) man page as a linux only behavior.
Thoughts?
Neil
^ permalink raw reply
* Re: [PATCH bpf] bpf: only adjust gso_size on bytestream protocols
From: Daniel Borkmann @ 2019-02-11 14:58 UTC (permalink / raw)
To: Alexei Starovoitov, Willem de Bruijn
Cc: netdev, ast, posk.devel, dja, Willem de Bruijn
In-Reply-To: <20190211040056.zqgi5qii26wtfs7i@ast-mbp>
Hi Willem,
On 02/11/2019 05:00 AM, Alexei Starovoitov wrote:
> On Thu, Feb 07, 2019 at 02:54:16PM -0500, Willem de Bruijn wrote:
>> From: Willem de Bruijn <willemb@google.com>
>>
>> bpf_skb_change_proto and bpf_skb_adjust_room change skb header length.
>> For GSO packets they adjust gso_size to maintain the same MTU.
>>
>> The gso size can only be safely adjusted on bytestream protocols.
>> Commit d02f51cbcf12 ("bpf: fix bpf_skb_adjust_net/bpf_skb_proto_xlat
>> to deal with gso sctp skbs") excluded SKB_GSO_SCTP.
>>
>> Since then type SKB_GSO_UDP_L4 has been added, whose contents are one
>> gso_size unit per datagram. Also exclude these.
>>
>> Move from a blacklist to a whitelist check to future proof against
>> additional such new GSO types, e.g., for fraglist based GRO.
>>
>> Fixes: bec1f6f69736 ("udp: generate gso with UDP_SEGMENT")
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> Applied to bpf tree.
> I agree that whitelist approach is the most appropriate.
What would be needed to get UDP GSO working with nat64 work above? I don't
really mind about SCTP, but sucks that this doesn't guarantee full support
for TCP *and* UDP at least. :/
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/7] Add __sk_buff->sk, bpf_tcp_sock, BPF_FUNC_tcp_sock and BPF_FUNC_sk_fullsock
From: Daniel Borkmann @ 2019-02-11 14:56 UTC (permalink / raw)
To: Alexei Starovoitov, Martin KaFai Lau
Cc: netdev, Alexei Starovoitov, kernel-team, Lawrence Brakmo
In-Reply-To: <20190211035541.3ghsfaksgtph6ak4@ast-mbp>
On 02/11/2019 04:55 AM, Alexei Starovoitov wrote:
> On Sat, Feb 09, 2019 at 11:22:20PM -0800, Martin KaFai Lau wrote:
>> This series adds __sk_buff->sk, "struct bpf_tcp_sock",
>> BPF_FUNC_sk_fullsock and BPF_FUNC_tcp_sock. Together, they provide
>> a common way to expose the members of "struct tcp_sock" and
>> "struct bpf_sock" for the bpf_prog to access.
>>
>> The patch series first adds a bpf_sock pointer to __sk_buff
>> and a new helper BPF_FUNC_sk_fullsock.
>>
>> It then adds BPF_FUNC_tcp_sock to get a bpf_tcp_sock
>> pointer from a bpf_sock pointer.
>>
>> The current use case is to allow a cg_skb_bpf_prog to provide
>> per cgroup traffic policing/shaping.
>>
>> Please see individual patch for details.
>>
>> v2:
>> - Patch 1 depends on
>> commit d623876646be ("bpf: Fix narrow load on a bpf_sock returned from sk_lookup()")
>> in the bpf branch.
>> - Add sk_to_full_sk() to bpf_sk_fullsock() and bpf_tcp_sock()
>> such that there is a way to access the listener's sk and tcp_sk
>> when __sk_buff->sk is a request_sock.
>> The comments in the uapi bpf.h is updated accordingly.
>> - bpf_ctx_range_till() is used in bpf_sock_common_is_valid_access()
>> in patch 1. Saved a few lines.
>> - Patch 2 is new in v2 and it adds "state", "dst_ip4", "dst_ip6" and
>> "dst_port" to the bpf_sock. Narrow load is allowed on them.
>> The "state" (i.e. sk_state) has already been used in
>> INET_DIAG (e.g. ss -t) and getsockopt(TCP_INFO).
>> - While at it in the new patch 2, also allow narrow load on some
>> existing fields of the bpf_sock, which are "family", "type", "protocol"
>> and "src_port". Only allow loading from first byte for now.
>> i.e. does not allow narrow load starting from the 2nd byte.
>> - Add some narrow load tests to the test_verifier's sock.c
>
> Daniel,
> I believe this new revision addresses your concerns exactly as we discussed.
> So I pushed it to bpf-next.
> please double check that it's what you expected.
> We can always revert.
> Thanks everyone!
Yep, looks better, thanks!
^ permalink raw reply
* [PATCH net] geneve: change NET_UDP_TUNNEL dependency to select
From: Matteo Croce @ 2019-02-11 14:32 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller
Due to the depends on NET_UDP_TUNNEL, at the moment it is impossible to
compile GENEVE if no other protocol depending on NET_UDP_TUNNEL is
selected.
Fix this changing the depends to a select, and drop NET_IP_TUNNEL from the
select list, as it already depends on NET_UDP_TUNNEL.
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Reviewed-and-tested-by: Andrea Claudi <aclaudi@redhat.com>
Tested-by: Davide Caratti <dcaratti@redhat.com>
---
drivers/net/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index edb1c023a753..21bf8ac78380 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -197,9 +197,9 @@ config VXLAN
config GENEVE
tristate "Generic Network Virtualization Encapsulation"
- depends on INET && NET_UDP_TUNNEL
+ depends on INET
depends on IPV6 || !IPV6
- select NET_IP_TUNNEL
+ select NET_UDP_TUNNEL
select GRO_CELLS
---help---
This allows one to create geneve virtual interfaces that provide
--
2.20.1
^ permalink raw reply related
* Re: stmmac / meson8b-dwmac
From: Jose Abreu @ 2019-02-11 13:44 UTC (permalink / raw)
To: Martin Blumenstingl, Simon Huelck
Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue,
linux-amlogic, netdev
In-Reply-To: <CAFBinCB1WUMOmaF6Wmr5HTutrgLOru5CRSnOpUUMMuVzHSa3Gg@mail.gmail.com>
Hello,
On 2/9/2019 1:09 AM, Martin Blumenstingl wrote:
> (it's interesting that the sending direction has 445 retries)
I saw this before and I think it was related with COE. Can you
please disable all offloading and try again?
Anyway, maybe Simon should bissect ? I think since 4.14 there are
not that many commits in stmmac / meson8b-dwmac that can cause
this behavior.
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH net-next 1/1] flow_offload: Fix flow action infrastructure
From: Jiri Pirko @ 2019-02-11 13:30 UTC (permalink / raw)
To: Eli Britstein
Cc: netdev, Roi Dayan, Pablo Neira Ayuso, Jiri Pirko, Saeed Mahameed
In-Reply-To: <20190211075259.39058-1-elibr@mellanox.com>
Mon, Feb 11, 2019 at 08:52:59AM CET, elibr@mellanox.com wrote:
>Implementation of macro "flow_action_for_each" introduced in
>commit e3ab786b42535 ("flow_offload: add flow action infrastructure")
>and used in commit 738678817573c ("drivers: net: use flow action
>infrastructure") iterated the first item twice and did not reach the
>last one. Fix it.
>
>Fixes: e3ab786b42535 ("flow_offload: add flow action infrastructure")
>Fixes: 738678817573c ("drivers: net: use flow action infrastructure")
>Signed-off-by: Eli Britstein <elibr@mellanox.com>
>Reviewed-by: Roi Dayan <roid@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
From: Felipe Balbi @ 2019-02-11 13:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
In-Reply-To: <20190211131243.GA21917@lst.de>
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
Hi,
Christoph Hellwig <hch@lst.de> writes:
> On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
>> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
>> > Christoph Hellwig <hch@lst.de> writes:
>> >
>> > > dma_map_single already transfers ownership to the device.
>> > >
>> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
>> >
>> > Do you want me to take the USB bits or will you take the entire series?
>> > In case you're taking the entire series:
>>
>> If you want to take the USB feel free. I just want most of this in
>> this merge window if possible.
>
> I didn't see in the USB tree yet, so please let me know if you want to
> take it.
sorry for the delay, just took it to my tree.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH] bpf: bpftool, fix documentation for attach types
From: Quentin Monnet @ 2019-02-11 13:26 UTC (permalink / raw)
To: Alban Crequy, ast, daniel; +Cc: netdev, linux-kernel, john.fastabend, alban
In-Reply-To: <20190211125426.21072-1-alban@kinvolk.io>
2019-02-11 13:54 UTC+0100 ~ Alban Crequy <alban.crequy@gmail.com>
> From: Alban Crequy <alban@kinvolk.io>
>
> bpftool has support for attach types "stream_verdict" and
> "stream_parser" but the documentation was referring to them with
> "skb_verdict" and "skb_parse". The inconsistency comes from commit
> b7d3826c2ed6 ("bpf: bpftool, add support for attaching programs to
> maps").
>
> This patch changes the documentation to match the implementation.
>
> Signed-off-by: Alban Crequy <alban@kinvolk.io>
> ---
> tools/bpf/bpftool/prog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> index 0640e9bc0ada..dfaa019a60f0 100644
> --- a/tools/bpf/bpftool/prog.c
> +++ b/tools/bpf/bpftool/prog.c
> @@ -1198,7 +1198,7 @@ static int do_help(int argc, char **argv)
> " cgroup/bind4 | cgroup/bind6 | cgroup/post_bind4 |\n"
> " cgroup/post_bind6 | cgroup/connect4 | cgroup/connect6 |\n"
> " cgroup/sendmsg4 | cgroup/sendmsg6 }\n"
> - " ATTACH_TYPE := { msg_verdict | skb_verdict | skb_parse |\n"
> + " ATTACH_TYPE := { msg_verdict | stream_verdict | stream_parser |\n"
> " flow_dissector }\n"
> " " HELP_SPEC_OPTIONS "\n"
> "",
>
Thanks Alban!
Could you please fix the man page and the bash completion file at the
same time?
Quentin
^ permalink raw reply
* net: don't pass a NULL struct device to DMA API functions v2
From: Christoph Hellwig @ 2019-02-11 13:19 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a struct device,
besides that there also is some arch code that needs separate handling,
a driver that should not use the DMA API at all, and one that is
a complete basket case to be deal with separately.
Changes since v1:
- fix an inverted ifdef in CAIF
- update the smc911x changelog
- split the series, this only contains the networking patches
^ permalink raw reply
* [PATCH 2/8] au1000_eth: pass struct device to DMA API functions
From: Christoph Hellwig @ 2019-02-11 13:19 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
In-Reply-To: <20190211132004.29143-1-hch@lst.de>
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/amd/au1000_eth.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/amd/au1000_eth.c b/drivers/net/ethernet/amd/au1000_eth.c
index e833d1b3fe18..e5073aeea06a 100644
--- a/drivers/net/ethernet/amd/au1000_eth.c
+++ b/drivers/net/ethernet/amd/au1000_eth.c
@@ -1167,7 +1167,7 @@ static int au1000_probe(struct platform_device *pdev)
/* Allocate the data buffers
* Snooping works fine with eth on all au1xxx
*/
- aup->vaddr = (u32)dma_alloc_attrs(NULL, MAX_BUF_SIZE *
+ aup->vaddr = (u32)dma_alloc_attrs(&pdev->dev, MAX_BUF_SIZE *
(NUM_TX_BUFFS + NUM_RX_BUFFS),
&aup->dma_addr, 0,
DMA_ATTR_NON_CONSISTENT);
@@ -1349,7 +1349,7 @@ static int au1000_probe(struct platform_device *pdev)
err_remap2:
iounmap(aup->mac);
err_remap1:
- dma_free_attrs(NULL, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
+ dma_free_attrs(&pdev->dev, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
(void *)aup->vaddr, aup->dma_addr,
DMA_ATTR_NON_CONSISTENT);
err_vaddr:
@@ -1383,7 +1383,7 @@ static int au1000_remove(struct platform_device *pdev)
if (aup->tx_db_inuse[i])
au1000_ReleaseDB(aup, aup->tx_db_inuse[i]);
- dma_free_attrs(NULL, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
+ dma_free_attrs(&pdev->dev, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
(void *)aup->vaddr, aup->dma_addr,
DMA_ATTR_NON_CONSISTENT);
--
2.20.1
^ permalink raw reply related
* [PATCH 3/8] macb_main: pass struct device to DMA API functions
From: Christoph Hellwig @ 2019-02-11 13:19 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
In-Reply-To: <20190211132004.29143-1-hch@lst.de>
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
drivers/net/ethernet/cadence/macb_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index eaabe8c278ec..4d1509f431d7 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3673,9 +3673,9 @@ static netdev_tx_t at91ether_start_xmit(struct sk_buff *skb,
/* Store packet information (to free when Tx completed) */
lp->skb = skb;
lp->skb_length = skb->len;
- lp->skb_physaddr = dma_map_single(NULL, skb->data, skb->len,
- DMA_TO_DEVICE);
- if (dma_mapping_error(NULL, lp->skb_physaddr)) {
+ lp->skb_physaddr = dma_map_single(&lp->pdev->dev, skb->data,
+ skb->len, DMA_TO_DEVICE);
+ if (dma_mapping_error(&lp->pdev->dev, lp->skb_physaddr)) {
dev_kfree_skb_any(skb);
dev->stats.tx_dropped++;
netdev_err(dev, "%s: DMA mapping error\n", __func__);
@@ -3765,7 +3765,7 @@ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
if (lp->skb) {
dev_kfree_skb_irq(lp->skb);
lp->skb = NULL;
- dma_unmap_single(NULL, lp->skb_physaddr,
+ dma_unmap_single(&lp->pdev->dev, lp->skb_physaddr,
lp->skb_length, DMA_TO_DEVICE);
dev->stats.tx_packets++;
dev->stats.tx_bytes += lp->skb_length;
--
2.20.1
^ permalink raw reply related
* [PATCH 5/8] pxa168_eth: pass struct device to DMA API functions
From: Christoph Hellwig @ 2019-02-11 13:20 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
In-Reply-To: <20190211132004.29143-1-hch@lst.de>
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note that this driver seems to entirely lack dma_map_single error
handling, but that is left for another time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/marvell/pxa168_eth.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index f8a6d6e3cb7a..35f2142aac5e 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -201,6 +201,7 @@ struct tx_desc {
};
struct pxa168_eth_private {
+ struct platform_device *pdev;
int port_num; /* User Ethernet port number */
int phy_addr;
int phy_speed;
@@ -331,7 +332,7 @@ static void rxq_refill(struct net_device *dev)
used_rx_desc = pep->rx_used_desc_q;
p_used_rx_desc = &pep->p_rx_desc_area[used_rx_desc];
size = skb_end_pointer(skb) - skb->data;
- p_used_rx_desc->buf_ptr = dma_map_single(NULL,
+ p_used_rx_desc->buf_ptr = dma_map_single(&pep->pdev->dev,
skb->data,
size,
DMA_FROM_DEVICE);
@@ -743,7 +744,7 @@ static int txq_reclaim(struct net_device *dev, int force)
netdev_err(dev, "Error in TX\n");
dev->stats.tx_errors++;
}
- dma_unmap_single(NULL, addr, count, DMA_TO_DEVICE);
+ dma_unmap_single(&pep->pdev->dev, addr, count, DMA_TO_DEVICE);
if (skb)
dev_kfree_skb_irq(skb);
released++;
@@ -805,7 +806,7 @@ static int rxq_process(struct net_device *dev, int budget)
if (rx_next_curr_desc == rx_used_desc)
pep->rx_resource_err = 1;
pep->rx_desc_count--;
- dma_unmap_single(NULL, rx_desc->buf_ptr,
+ dma_unmap_single(&pep->pdev->dev, rx_desc->buf_ptr,
rx_desc->buf_size,
DMA_FROM_DEVICE);
received_packets++;
@@ -1274,7 +1275,8 @@ pxa168_eth_start_xmit(struct sk_buff *skb, struct net_device *dev)
length = skb->len;
pep->tx_skb[tx_index] = skb;
desc->byte_cnt = length;
- desc->buf_ptr = dma_map_single(NULL, skb->data, length, DMA_TO_DEVICE);
+ desc->buf_ptr = dma_map_single(&pep->pdev->dev, skb->data, length,
+ DMA_TO_DEVICE);
skb_tx_timestamp(skb);
@@ -1528,6 +1530,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
if (err)
goto err_free_mdio;
+ pep->pdev = pdev;
SET_NETDEV_DEV(dev, &pdev->dev);
pxa168_init_hw(pep);
err = register_netdev(dev);
--
2.20.1
^ permalink raw reply related
* [PATCH 6/8] moxart_ether: pass struct device to DMA API functions
From: Christoph Hellwig @ 2019-02-11 13:20 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
In-Reply-To: <20190211132004.29143-1-hch@lst.de>
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/moxa/moxart_ether.c | 11 +++++++----
drivers/net/ethernet/moxa/moxart_ether.h | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index b34055ac476f..00dec0ffb11b 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -81,11 +81,13 @@ static void moxart_mac_free_memory(struct net_device *ndev)
priv->rx_buf_size, DMA_FROM_DEVICE);
if (priv->tx_desc_base)
- dma_free_coherent(NULL, TX_REG_DESC_SIZE * TX_DESC_NUM,
+ dma_free_coherent(&priv->pdev->dev,
+ TX_REG_DESC_SIZE * TX_DESC_NUM,
priv->tx_desc_base, priv->tx_base);
if (priv->rx_desc_base)
- dma_free_coherent(NULL, RX_REG_DESC_SIZE * RX_DESC_NUM,
+ dma_free_coherent(&priv->pdev->dev,
+ RX_REG_DESC_SIZE * RX_DESC_NUM,
priv->rx_desc_base, priv->rx_base);
kfree(priv->tx_buf_base);
@@ -476,6 +478,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
priv = netdev_priv(ndev);
priv->ndev = ndev;
+ priv->pdev = pdev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ndev->base_addr = res->start;
@@ -491,7 +494,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
priv->tx_buf_size = TX_BUF_SIZE;
priv->rx_buf_size = RX_BUF_SIZE;
- priv->tx_desc_base = dma_alloc_coherent(NULL, TX_REG_DESC_SIZE *
+ priv->tx_desc_base = dma_alloc_coherent(&pdev->dev, TX_REG_DESC_SIZE *
TX_DESC_NUM, &priv->tx_base,
GFP_DMA | GFP_KERNEL);
if (!priv->tx_desc_base) {
@@ -499,7 +502,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
goto init_fail;
}
- priv->rx_desc_base = dma_alloc_coherent(NULL, RX_REG_DESC_SIZE *
+ priv->rx_desc_base = dma_alloc_coherent(&pdev->dev, RX_REG_DESC_SIZE *
RX_DESC_NUM, &priv->rx_base,
GFP_DMA | GFP_KERNEL);
if (!priv->rx_desc_base) {
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
index bee608b547d1..bf4c3029cd0c 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.h
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -292,6 +292,7 @@
#define LINK_STATUS 0x4
struct moxart_mac_priv_t {
+ struct platform_device *pdev;
void __iomem *base;
unsigned int reg_maccr;
unsigned int reg_imr;
--
2.20.1
^ permalink raw reply related
* [PATCH 4/8] lantiq_etop: pass struct device to DMA API functions
From: Christoph Hellwig @ 2019-02-11 13:20 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
In-Reply-To: <20190211132004.29143-1-hch@lst.de>
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note this driver seems to lack dma_unmap_* calls entirely, but fixing
that is left for another time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/lantiq_etop.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/lantiq_etop.c b/drivers/net/ethernet/lantiq_etop.c
index 32ac9045cdae..f9bb890733b5 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -112,10 +112,12 @@ struct ltq_etop_priv {
static int
ltq_etop_alloc_skb(struct ltq_etop_chan *ch)
{
+ struct ltq_etop_priv *priv = netdev_priv(ch->netdev);
+
ch->skb[ch->dma.desc] = netdev_alloc_skb(ch->netdev, MAX_DMA_DATA_LEN);
if (!ch->skb[ch->dma.desc])
return -ENOMEM;
- ch->dma.desc_base[ch->dma.desc].addr = dma_map_single(NULL,
+ ch->dma.desc_base[ch->dma.desc].addr = dma_map_single(&priv->pdev->dev,
ch->skb[ch->dma.desc]->data, MAX_DMA_DATA_LEN,
DMA_FROM_DEVICE);
ch->dma.desc_base[ch->dma.desc].addr =
@@ -487,7 +489,7 @@ ltq_etop_tx(struct sk_buff *skb, struct net_device *dev)
netif_trans_update(dev);
spin_lock_irqsave(&priv->lock, flags);
- desc->addr = ((unsigned int) dma_map_single(NULL, skb->data, len,
+ desc->addr = ((unsigned int) dma_map_single(&priv->pdev->dev, skb->data, len,
DMA_TO_DEVICE)) - byte_offset;
wmb();
desc->ctl = LTQ_DMA_OWN | LTQ_DMA_SOP | LTQ_DMA_EOP |
--
2.20.1
^ permalink raw reply related
* [PATCH 8/8] smc911x: pass struct device to DMA API functions
From: Christoph Hellwig @ 2019-02-11 13:20 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
In-Reply-To: <20190211132004.29143-1-hch@lst.de>
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note that smc911x apparently is a PIO chip with an external DMA
handshake, and we probably use the wrong device here. But at least
it matches the mapping side, which apparently works or at least
worked in the not too distant past.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/smsc/smc911x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
index 8355dfbb8ec3..b550e624500d 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -1188,7 +1188,7 @@ smc911x_tx_dma_irq(void *data)
DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
BUG_ON(skb == NULL);
- dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
+ dma_unmap_single(lp->dev, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
netif_trans_update(dev);
dev_kfree_skb_irq(skb);
lp->current_tx_skb = NULL;
@@ -1219,7 +1219,7 @@ smc911x_rx_dma_irq(void *data)
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
- dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
+ dma_unmap_single(lp->dev, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
BUG_ON(skb == NULL);
lp->current_rx_skb = NULL;
PRINT_PKT(skb->data, skb->len);
--
2.20.1
^ permalink raw reply related
* [PATCH 7/8] meth: pass struct device to DMA API functions
From: Christoph Hellwig @ 2019-02-11 13:20 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
In-Reply-To: <20190211132004.29143-1-hch@lst.de>
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't in interrupt context or under a lock.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/sgi/meth.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/sgi/meth.c b/drivers/net/ethernet/sgi/meth.c
index 0e1b7e960b98..67954a9e3675 100644
--- a/drivers/net/ethernet/sgi/meth.c
+++ b/drivers/net/ethernet/sgi/meth.c
@@ -68,6 +68,8 @@ module_param(timeout, int, 0);
* packets in and out, so there is place for a packet
*/
struct meth_private {
+ struct platform_device *pdev;
+
/* in-memory copy of MAC Control register */
u64 mac_ctrl;
@@ -211,8 +213,8 @@ static void meth_check_link(struct net_device *dev)
static int meth_init_tx_ring(struct meth_private *priv)
{
/* Init TX ring */
- priv->tx_ring = dma_alloc_coherent(NULL, TX_RING_BUFFER_SIZE,
- &priv->tx_ring_dma, GFP_ATOMIC);
+ priv->tx_ring = dma_alloc_coherent(&priv->pdev->dev,
+ TX_RING_BUFFER_SIZE, &priv->tx_ring_dma, GFP_KERNEL);
if (!priv->tx_ring)
return -ENOMEM;
@@ -236,7 +238,7 @@ static int meth_init_rx_ring(struct meth_private *priv)
priv->rx_ring[i]=(rx_packet*)(priv->rx_skbs[i]->head);
/* I'll need to re-sync it after each RX */
priv->rx_ring_dmas[i] =
- dma_map_single(NULL, priv->rx_ring[i],
+ dma_map_single(&priv->pdev->dev, priv->rx_ring[i],
METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
mace->eth.rx_fifo = priv->rx_ring_dmas[i];
}
@@ -253,7 +255,7 @@ static void meth_free_tx_ring(struct meth_private *priv)
dev_kfree_skb(priv->tx_skbs[i]);
priv->tx_skbs[i] = NULL;
}
- dma_free_coherent(NULL, TX_RING_BUFFER_SIZE, priv->tx_ring,
+ dma_free_coherent(&priv->pdev->dev, TX_RING_BUFFER_SIZE, priv->tx_ring,
priv->tx_ring_dma);
}
@@ -263,7 +265,7 @@ static void meth_free_rx_ring(struct meth_private *priv)
int i;
for (i = 0; i < RX_RING_ENTRIES; i++) {
- dma_unmap_single(NULL, priv->rx_ring_dmas[i],
+ dma_unmap_single(&priv->pdev->dev, priv->rx_ring_dmas[i],
METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
priv->rx_ring[i] = 0;
priv->rx_ring_dmas[i] = 0;
@@ -393,7 +395,8 @@ static void meth_rx(struct net_device* dev, unsigned long int_status)
fifo_rptr = (fifo_rptr - 1) & 0x0f;
}
while (priv->rx_write != fifo_rptr) {
- dma_unmap_single(NULL, priv->rx_ring_dmas[priv->rx_write],
+ dma_unmap_single(&priv->pdev->dev,
+ priv->rx_ring_dmas[priv->rx_write],
METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
status = priv->rx_ring[priv->rx_write]->status.raw;
#if MFE_DEBUG
@@ -454,7 +457,8 @@ static void meth_rx(struct net_device* dev, unsigned long int_status)
priv->rx_ring[priv->rx_write] = (rx_packet*)skb->head;
priv->rx_ring[priv->rx_write]->status.raw = 0;
priv->rx_ring_dmas[priv->rx_write] =
- dma_map_single(NULL, priv->rx_ring[priv->rx_write],
+ dma_map_single(&priv->pdev->dev,
+ priv->rx_ring[priv->rx_write],
METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
mace->eth.rx_fifo = priv->rx_ring_dmas[priv->rx_write];
ADVANCE_RX_PTR(priv->rx_write);
@@ -637,7 +641,7 @@ static void meth_tx_1page_prepare(struct meth_private *priv,
}
/* first page */
- catbuf = dma_map_single(NULL, buffer_data, buffer_len,
+ catbuf = dma_map_single(&priv->pdev->dev, buffer_data, buffer_len,
DMA_TO_DEVICE);
desc->data.cat_buf[0].form.start_addr = catbuf >> 3;
desc->data.cat_buf[0].form.len = buffer_len - 1;
@@ -663,12 +667,12 @@ static void meth_tx_2page_prepare(struct meth_private *priv,
}
/* first page */
- catbuf1 = dma_map_single(NULL, buffer1_data, buffer1_len,
+ catbuf1 = dma_map_single(&priv->pdev->dev, buffer1_data, buffer1_len,
DMA_TO_DEVICE);
desc->data.cat_buf[0].form.start_addr = catbuf1 >> 3;
desc->data.cat_buf[0].form.len = buffer1_len - 1;
/* second page */
- catbuf2 = dma_map_single(NULL, buffer2_data, buffer2_len,
+ catbuf2 = dma_map_single(&priv->pdev->dev, buffer2_data, buffer2_len,
DMA_TO_DEVICE);
desc->data.cat_buf[1].form.start_addr = catbuf2 >> 3;
desc->data.cat_buf[1].form.len = buffer2_len - 1;
@@ -840,6 +844,7 @@ static int meth_probe(struct platform_device *pdev)
memcpy(dev->dev_addr, o2meth_eaddr, ETH_ALEN);
priv = netdev_priv(dev);
+ priv->pdev = pdev;
spin_lock_init(&priv->meth_lock);
SET_NETDEV_DEV(dev, &pdev->dev);
--
2.20.1
^ permalink raw reply related
* [PATCH 1/8] net: caif: pass struct device to DMA API functions
From: Christoph Hellwig @ 2019-02-11 13:19 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Nicolas Ferre, iommu, linux-kernel
In-Reply-To: <20190211132004.29143-1-hch@lst.de>
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/caif/caif_spi.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index d28a1398c091..7608bc3e00df 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -73,35 +73,37 @@ MODULE_PARM_DESC(spi_down_tail_align, "SPI downlink tail alignment.");
#define LOW_WATER_MARK 100
#define HIGH_WATER_MARK (LOW_WATER_MARK*5)
-#ifdef CONFIG_UML
+#ifndef CONFIG_HAS_DMA
/*
* We sometimes use UML for debugging, but it cannot handle
* dma_alloc_coherent so we have to wrap it.
*/
-static inline void *dma_alloc(dma_addr_t *daddr)
+static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
{
return kmalloc(SPI_DMA_BUF_LEN, GFP_KERNEL);
}
-static inline void dma_free(void *cpu_addr, dma_addr_t handle)
+static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
+ dma_addr_t handle)
{
kfree(cpu_addr);
}
#else
-static inline void *dma_alloc(dma_addr_t *daddr)
+static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
{
- return dma_alloc_coherent(NULL, SPI_DMA_BUF_LEN, daddr,
+ return dma_alloc_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, daddr,
GFP_KERNEL);
}
-static inline void dma_free(void *cpu_addr, dma_addr_t handle)
+static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
+ dma_addr_t handle)
{
- dma_free_coherent(NULL, SPI_DMA_BUF_LEN, cpu_addr, handle);
+ dma_free_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, cpu_addr, handle);
}
-#endif /* CONFIG_UML */
+#endif /* CONFIG_HAS_DMA */
#ifdef CONFIG_DEBUG_FS
@@ -610,13 +612,13 @@ static int cfspi_init(struct net_device *dev)
}
/* Allocate DMA buffers. */
- cfspi->xfer.va_tx[0] = dma_alloc(&cfspi->xfer.pa_tx[0]);
+ cfspi->xfer.va_tx[0] = dma_alloc(cfspi, &cfspi->xfer.pa_tx[0]);
if (!cfspi->xfer.va_tx[0]) {
res = -ENODEV;
goto err_dma_alloc_tx_0;
}
- cfspi->xfer.va_rx = dma_alloc(&cfspi->xfer.pa_rx);
+ cfspi->xfer.va_rx = dma_alloc(cfspi, &cfspi->xfer.pa_rx);
if (!cfspi->xfer.va_rx) {
res = -ENODEV;
@@ -665,9 +667,9 @@ static int cfspi_init(struct net_device *dev)
return 0;
err_create_wq:
- dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
+ dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
err_dma_alloc_rx:
- dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
+ dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
err_dma_alloc_tx_0:
return res;
}
@@ -683,8 +685,8 @@ static void cfspi_uninit(struct net_device *dev)
cfspi->ndev = NULL;
/* Free DMA buffers. */
- dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
- dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
+ dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
+ dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
set_bit(SPI_TERMINATE, &cfspi->state);
wake_up_interruptible(&cfspi->wait);
destroy_workqueue(cfspi->wq);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
From: Christoph Hellwig @ 2019-02-11 13:12 UTC (permalink / raw)
To: Felipe Balbi
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
In-Reply-To: <20190201161026.GE6532@lst.de>
On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> >
> > > dma_map_single already transfers ownership to the device.
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > Do you want me to take the USB bits or will you take the entire series?
> > In case you're taking the entire series:
>
> If you want to take the USB feel free. I just want most of this in
> this merge window if possible.
I didn't see in the USB tree yet, so please let me know if you want to
take it.
^ permalink raw reply
* Re: [PATCH net-next v2 4/5] nfp: devlink: use the generic manufacture identifier instead of vendor
From: Jiri Pirko @ 2019-02-11 13:01 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, oss-drivers
In-Reply-To: <20190211033531.12928-5-jakub.kicinski@netronome.com>
Mon, Feb 11, 2019 at 04:35:30AM CET, jakub.kicinski@netronome.com wrote:
>Vendor may sound ambiguous, let's rename the fab string to
>"board.manufacture" (which was just added as a generic identifier).
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v2 5/5] nfp: devlink: include vendor/product info in serial number
From: Jiri Pirko @ 2019-02-11 13:01 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, oss-drivers
In-Reply-To: <20190211033531.12928-6-jakub.kicinski@netronome.com>
Mon, Feb 11, 2019 at 04:35:31AM CET, jakub.kicinski@netronome.com wrote:
>The manufacturing team requests we include vendor and product
>in the serial number field, as the serial number itself is not
>unique across manufacturing facilities and products.
Oups.
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] devlink: add a generic board.manufacture version name
From: Jiri Pirko @ 2019-02-11 12:59 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, oss-drivers
In-Reply-To: <20190211033531.12928-4-jakub.kicinski@netronome.com>
Mon, Feb 11, 2019 at 04:35:29AM CET, jakub.kicinski@netronome.com wrote:
>At Jiri's suggestion add a generic "board.manufacture"
>version identifier.
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v3 9/9] net: Remove switchdev_ops
From: Jiri Pirko @ 2019-02-11 12:51 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, idosch, linux-kernel, devel, bridge, jiri, andrew,
vivien.didelot
In-Reply-To: <20190210234007.16173-10-f.fainelli@gmail.com>
Mon, Feb 11, 2019 at 12:40:07AM CET, f.fainelli@gmail.com wrote:
>Now that we have converted all possible callers to using a switchdev
>notifier for attributes we do not have a need for implementing
>switchdev_ops anymore, and this can be removed from all drivers the
>net_device structure.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH] bpf: bpftool, fix documentation for attach types
From: Alban Crequy @ 2019-02-11 12:54 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linux-kernel, john.fastabend, alban
From: Alban Crequy <alban@kinvolk.io>
bpftool has support for attach types "stream_verdict" and
"stream_parser" but the documentation was referring to them with
"skb_verdict" and "skb_parse". The inconsistency comes from commit
b7d3826c2ed6 ("bpf: bpftool, add support for attaching programs to
maps").
This patch changes the documentation to match the implementation.
Signed-off-by: Alban Crequy <alban@kinvolk.io>
---
tools/bpf/bpftool/prog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index 0640e9bc0ada..dfaa019a60f0 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -1198,7 +1198,7 @@ static int do_help(int argc, char **argv)
" cgroup/bind4 | cgroup/bind6 | cgroup/post_bind4 |\n"
" cgroup/post_bind6 | cgroup/connect4 | cgroup/connect6 |\n"
" cgroup/sendmsg4 | cgroup/sendmsg6 }\n"
- " ATTACH_TYPE := { msg_verdict | skb_verdict | skb_parse |\n"
+ " ATTACH_TYPE := { msg_verdict | stream_verdict | stream_parser |\n"
" flow_dissector }\n"
" " HELP_SPEC_OPTIONS "\n"
"",
--
2.20.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