* Re: [oss-drivers] Re: [PATCH net-next] net/tls: prevent skb_orphan() from leaking TLS plain text with offload
From: Willem de Bruijn @ 2019-07-31 19:07 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David Miller, Network Development, oss-drivers, Eric Dumazet,
borisp, aviadye, davejwatson, John Fastabend, Daniel Borkmann,
Cong Wang, Florian Westphal, Alexei Starovoitov
In-Reply-To: <20190731111213.35237adc@cakuba.netronome.com>
On Wed, Jul 31, 2019 at 2:12 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Wed, 31 Jul 2019 11:57:10 -0400, Willem de Bruijn wrote:
> > On Tue, Jul 30, 2019 at 5:13 PM Jakub Kicinski wrote:
> > > sk_validate_xmit_skb() and drivers depend on the sk member of
> > > struct sk_buff to identify segments requiring encryption.
> > > Any operation which removes or does not preserve the original TLS
> > > socket such as skb_orphan() or skb_clone() will cause clear text
> > > leaks.
> > >
> > > Make the TCP socket underlying an offloaded TLS connection
> > > mark all skbs as decrypted, if TLS TX is in offload mode.
> > > Then in sk_validate_xmit_skb() catch skbs which have no socket
> > > (or a socket with no validation) and decrypted flag set.
> > >
> > > Note that CONFIG_SOCK_VALIDATE_XMIT, CONFIG_TLS_DEVICE and
> > > sk->sk_validate_xmit_skb are slightly interchangeable right now,
> > > they all imply TLS offload. The new checks are guarded by
> > > CONFIG_TLS_DEVICE because that's the option guarding the
> > > sk_buff->decrypted member.
> > >
> > > Second, smaller issue with orphaning is that it breaks
> > > the guarantee that packets will be delivered to device
> > > queues in-order. All TLS offload drivers depend on that
> > > scheduling property. This means skb_orphan_partial()'s
> > > trick of preserving partial socket references will cause
> > > issues in the drivers. We need a full orphan, and as a
> > > result netem delay/throttling will cause all TLS offload
> > > skbs to be dropped.
> > >
> > > Reusing the sk_buff->decrypted flag also protects from
> > > leaking clear text when incoming, decrypted skb is redirected
> > > (e.g. by TC).
> > >
> > > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> > > diff --git a/net/core/sock.c b/net/core/sock.c
> > > index d57b0cc995a0..b0c10b518e65 100644
> > > --- a/net/core/sock.c
> > > +++ b/net/core/sock.c
> > > @@ -1992,6 +1992,22 @@ void skb_set_owner_w(struct sk_buff *skb, struct sock *sk)
> > > }
> > > EXPORT_SYMBOL(skb_set_owner_w);
> > >
> > > +static bool can_skb_orphan_partial(const struct sk_buff *skb)
> > > +{
> > > +#ifdef CONFIG_TLS_DEVICE
> > > + /* Drivers depend on in-order delivery for crypto offload,
> > > + * partial orphan breaks out-of-order-OK logic.
> > > + */
> > > + if (skb->decrypted)
> > > + return false;
> > > +#endif
> > > +#ifdef CONFIG_INET
> > > + if (skb->destructor == tcp_wfree)
> > > + return true;
> > > +#endif
> > > + return skb->destructor == sock_wfree;
> > > +}
> > > +
> >
> > Just insert the skb->decrypted check into skb_orphan_partial for less
> > code churn?
>
> Okie.. skb_orphan_partial() is a little ugly but will do.
>
> > I also think that this is an independent concern from leaking plain
> > text, so perhaps could be a separate patch.
Just a suggestion and very much depending on how much uglier it
becomes otherwise ;)
> Do you mean the out-of-order stuff is a separate concern?
>
> It is, I had them separate at the first try, but GSO code looks at
> the destructor and IIRC only copies the socket if its still tcp_wfree.
> If we let partial orphan be we have to do temporary hairy stuff in
> tcp_gso_segment(). It's easier to just deal with partial orphan here.
Okay, sounds good.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Andy Lutomirski @ 2019-07-31 19:09 UTC (permalink / raw)
To: Song Liu
Cc: Andy Lutomirski, Kees Cook, Networking, bpf, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Lorenz Bauer, Jann Horn, Greg KH,
Linux API, LSM List
In-Reply-To: <D4040C0C-47D6-4852-933C-59EB53C05242@fb.com>
On Wed, Jul 31, 2019 at 1:10 AM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jul 30, 2019, at 1:24 PM, Andy Lutomirski <luto@kernel.org> wrote:
> >
> > On Mon, Jul 29, 2019 at 10:07 PM Song Liu <songliubraving@fb.com> wrote:
> >>
> >> Hi Andy,
> >>
> >>> On Jul 27, 2019, at 11:20 AM, Song Liu <songliubraving@fb.com> wrote:
> >>>
> >>> Hi Andy,
> >>>
> >>>
>
> [...]
>
> >>>
> >>
> >> I would like more comments on this.
> >>
> >> Currently, bpf permission is more or less "root or nothing", which we
> >> would like to change.
> >>
> >> The short term goal is to separate bpf from root, in other words, it is
> >> "all or nothing". Special user space utilities, such as systemd, would
> >> benefit from this. Once this is implemented, systemd can call sys_bpf()
> >> when it is not running as root.
> >
> > As generally nasty as Linux capabilities are, this sounds like a good
> > use for CAP_BPF_ADMIN.
>
> I actually agree CAP_BPF_ADMIN makes sense. The hard part is to make
> existing tools (setcap, getcap, etc.) and libraries aware of the new CAP.
It's been done before -- it's not that hard. IMO the main tricky bit
would be try be somewhat careful about defining exactly what
CAP_BPF_ADMIN does.
> > I don't see why you need to invent a whole new mechanism for this.
> > The entire cgroup ecosystem outside bpf() does just fine using the
> > write permission on files in cgroupfs to control access. Why can't
> > bpf() do the same thing?
>
> It is easier to use write permission for BPF_PROG_ATTACH. But it is
> not easy to do the same for other bpf commands: BPF_PROG_LOAD and
> BPF_MAP_*. A lot of these commands don't have target concept. Maybe
> we should have target concept for all these commands. But that is a
> much bigger project. OTOH, "all or nothing" model allows all these
> commands at once.
For BPF_PROG_LOAD, I admit I've never understood why permission is
required at all. I think that CAP_SYS_ADMIN or similar should be
needed to get is_priv in the verifier, but I think that should mainly
be useful for tracing, and that requires lots of privilege anyway.
BPF_MAP_* is probably the trickiest part. One solution would be some
kind of bpffs, but I'm sure other solutions are possible.
^ permalink raw reply
* Re: [PATCH bpf-next v10 06/10] bpf,landlock: Add a new map type: inode
From: Mickaël Salaün @ 2019-07-31 19:11 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Mickaël Salaün, LKML, Alexander Viro,
Alexei Starovoitov, Andrew Morton, Andy Lutomirski,
Arnaldo Carvalho de Melo, Casey Schaufler, Daniel Borkmann,
David Drysdale, David S . Miller, Eric W . Biederman,
James Morris, Jann Horn, John Johansen, Jonathan Corbet,
Kees Cook, Michael Kerrisk, Paul Moore, Sargun Dhillon,
Serge E . Hallyn, Shuah Khan, Stephen Smalley, Tejun Heo,
Tetsuo Handa, Thomas Graf, Tycho Andersen, Will Drewry,
Kernel Hardening, Linux API, Linux-Fsdevel, LSM List,
Network Development
In-Reply-To: <CAADnVQLqkfVijWoOM29PxCL_yK6K0fr8B89r4c5EKgddevJhGQ@mail.gmail.com>
On 31/07/2019 20:58, Alexei Starovoitov wrote:
> On Wed, Jul 31, 2019 at 11:46 AM Mickaël Salaün
> <mickael.salaun@ssi.gouv.fr> wrote:
>>>> + for (i = 0; i < htab->n_buckets; i++) {
>>>> + head = select_bucket(htab, i);
>>>> + hlist_nulls_for_each_entry_safe(l, n, head, hash_node) {
>>>> + landlock_inode_remove_map(*((struct inode **)l->key), map);
>>>> + }
>>>> + }
>>>> + htab_map_free(map);
>>>> +}
>>>
>>> user space can delete the map.
>>> that will trigger inode_htab_map_free() which will call
>>> landlock_inode_remove_map().
>>> which will simply itereate the list and delete from the list.
>>
>> landlock_inode_remove_map() removes the reference to the map (being
>> freed) from the inode (with an RCU lock).
>
> I'm going to ignore everything else for now and focus only on this bit,
> since it's fundamental issue to address before this discussion can
> go any further.
> rcu_lock is not a spin_lock. I'm pretty sure you know this.
> But you're arguing that it's somehow protecting from the race
> I mentioned above?
>
I was just clarifying your comment to avoid misunderstanding about what
is being removed.
As said in the full response, there is currently a race but, if I add a
bpf_map_inc() call when the map is referenced by inode->security, then I
don't see how a race could occur because such added map could only be
freed in a security_inode_free() (as long as it retains a reference to
this inode).
--
Mickaël Salaün
ANSSI/SDE/ST/LAM
Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.
^ permalink raw reply
* Re: [PATCH net-next 0/6] flow_offload: add indr-block in nf_table_offload
From: Jiri Pirko @ 2019-07-31 19:21 UTC (permalink / raw)
To: wenxu; +Cc: pablo, fw, jakub.kicinski, netfilter-devel, netdev
In-Reply-To: <1564560753-32603-1-git-send-email-wenxu@ucloud.cn>
Wed, Jul 31, 2019 at 10:12:27AM CEST, wenxu@ucloud.cn wrote:
>From: wenxu <wenxu@ucloud.cn>
>
>This series patch make nftables offload support the vlan and
>tunnel device offload through indr-block architecture.
>
>The first four patches mv tc indr block to flow offload and
>rename to flow-indr-block.
>Because the new flow-indr-block can't get the tcf_block
>directly. The fifthe patch provide a callback list to get
>flow_block of each subsystem immediately when the device
>register and contain a block.
>The last patch make nf_tables_offload support flow-indr-block.
>
>wenxu (6):
> cls_api: modify the tc_indr_block_ing_cmd parameters.
> cls_api: replace block with flow_block in tc_indr_block_dev
> cls_api: add flow_indr_block_call function
> flow_offload: move tc indirect block to flow offload
> flow_offload: support get flow_block immediately
> netfilter: nf_tables_offload: support indr block call
Wenxu, this is V5. Please repost is as V5. Also please provide per-patch
changelog, as you did with the previous versions. Thanks!
^ permalink raw reply
* Re: [PATCH v2 bpf-next 02/12] libbpf: implement BPF CO-RE offset relocation algorithm
From: Song Liu @ 2019-07-31 17:46 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, bpf, netdev@vger.kernel.org, Alexei Starovoitov,
daniel@iogearbox.net, Yonghong Song, Kernel Team
In-Reply-To: <CAEf4Bzb6swYtf7J_m1bZo6o+aT1AcCXZX5ZBw7Uja=Tne2LCuw@mail.gmail.com>
> On Jul 31, 2019, at 10:18 AM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Wed, Jul 31, 2019 at 1:30 AM Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Jul 30, 2019, at 11:52 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>>>
>>> On Tue, Jul 30, 2019 at 10:19 PM Song Liu <songliubraving@fb.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Jul 30, 2019, at 6:00 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>>>>>
>>>>> On Tue, Jul 30, 2019 at 5:39 PM Song Liu <songliubraving@fb.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jul 30, 2019, at 12:53 PM, Andrii Nakryiko <andriin@fb.com> wrote:
>>>>>>>
>>>>>>> This patch implements the core logic for BPF CO-RE offsets relocations.
>>>>>>> Every instruction that needs to be relocated has corresponding
>>>>>>> bpf_offset_reloc as part of BTF.ext. Relocations are performed by trying
>>>>>>> to match recorded "local" relocation spec against potentially many
>>>>>>> compatible "target" types, creating corresponding spec. Details of the
>>>>>>> algorithm are noted in corresponding comments in the code.
>>>>>>>
>>>>>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>
>> [...]
>>
>>>>>>
>>>>>
>>>>> I just picked the most succinct and non-repetitive form. It's
>>>>> immediately apparent which type it's implicitly converted to, so I
>>>>> felt there is no need to repeat it. Also, just (void *) is much
>>>>> shorter. :)
>>>>
>>>> _All_ other code in btf.c converts the pointer to the target type.
>>>
>>> Most in libbpf.c doesn't, though. Also, I try to preserve pointer
>>> constness for uses that don't modify BTF types (pretty much all of
>>> them in libbpf), so it becomes really verbose, despite extremely short
>>> variable names:
>>>
>>> const struct btf_member *m = (const struct btf_member *)(t + 1);
>>
>> I don't think being verbose is a big problem here. Overusing
>
> Problem is too big and strong word to describe this :). It hurts
> readability and will often quite artificially force either wrapping
> the line or unnecessarily splitting declaration and assignment. Void *
> on the other hand is short and usually is in the same line as target
> type declaration, if not, you'll have to find local variable
> declaration to double-check type, if you are unsure.
>
> Using (void *) + implicit cast to target pointer type is not
> unprecedented in libbpf:
>
> $ rg ' = \((const )?struct \w+ \*\)' tools/lib/bpf/ | wc -l
> 52
> $ rg ' = \((const )?void \*\)' tools/lib/bpf/ | wc -l
> 35
>
> 52 vs 35 is majority overall, but not by a landslide.
>
>> (void *) feels like a bigger problem.
>
> Why do you feel it's a problem? void * conveys that we have a piece of
> memory that we will need to reinterpret as some concrete pointer type.
> That's what we are doing, skipping btf_type and then interpreting
> memory after common btf_type prefix is some other type, depending on
> actual BTF kind. I don't think void * is misleading in any way.
(void *) hides some problem. For example:
struct type_a *ptr_a = NULL;
struct type_b *ptr_b = NULL;
/* we want this */
ptr_a = (struct type_a *)data;
ptr_b = (struct type_b *)(data + offset);
/* typo, should be ptr_b, compiler will complain */
ptr_a = (struct type_b *)(data + offset);
/* typo, should be ptr_b, compiler will ignore */
ptr_a = (void *)(data + offset);
Such typo is not very rare. And it may be really painful to debug.
That being said, I think we have spent too much time on this. I will
let you make the final call. Either way:
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [patch net-next v2 1/3] net: devlink: allow to change namespaces
From: Jiri Pirko @ 2019-07-31 19:26 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem, sthemmin, dsahern, mlxsw
In-Reply-To: <20190730153952.73de7f00@cakuba.netronome.com>
Wed, Jul 31, 2019 at 12:39:52AM CEST, jakub.kicinski@netronome.com wrote:
>On Tue, 30 Jul 2019 10:57:32 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> All devlink instances are created in init_net and stay there for a
>> lifetime. Allow user to be able to move devlink instances into
>> namespaces.
>>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>
>I'm no namespace expert, but seems reasonable, so FWIW:
>
>Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
>If I read things right we will only send the devlink instance
>notification to other namespaces when it moves, but not
>notifications for sub-objects like ports. Is the expectation
>that the user space dumps the objects it cares about or will
>the other notifications be added as needed (or option 3 - I
>misread the code).
You are correct. I plan to take care of the notifications of all objects
in the follow-up patchset. But I can do it in this one if needed. Up to
you.
>
>I was also wondering it moving the devlink instance during a
>multi-part transaction could be an issue. But AFAIU it should
>be fine - the flashing doesn't release the instance lock, and
>health stuff should complete correctly even if devlink is moved
>half way through?
Yes, I don't see any issue there as well.
^ permalink raw reply
* Re: [PATCH V2 7/9] vhost: do not use RCU to synchronize MMU notifier with worker
From: Jason Gunthorpe @ 2019-07-31 19:30 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, kvm, virtualization, netdev, linux-kernel, linux-mm
In-Reply-To: <7555c949-ae6f-f105-6e1d-df21ddae9e4e@redhat.com>
On Wed, Jul 31, 2019 at 09:28:20PM +0800, Jason Wang wrote:
>
> On 2019/7/31 下午8:39, Jason Gunthorpe wrote:
> > On Wed, Jul 31, 2019 at 04:46:53AM -0400, Jason Wang wrote:
> > > We used to use RCU to synchronize MMU notifier with worker. This leads
> > > calling synchronize_rcu() in invalidate_range_start(). But on a busy
> > > system, there would be many factors that may slow down the
> > > synchronize_rcu() which makes it unsuitable to be called in MMU
> > > notifier.
> > >
> > > A solution is SRCU but its overhead is obvious with the expensive full
> > > memory barrier. Another choice is to use seqlock, but it doesn't
> > > provide a synchronization method between readers and writers. The last
> > > choice is to use vq mutex, but it need to deal with the worst case
> > > that MMU notifier must be blocked and wait for the finish of swap in.
> > >
> > > So this patch switches use a counter to track whether or not the map
> > > was used. The counter was increased when vq try to start or finish
> > > uses the map. This means, when it was even, we're sure there's no
> > > readers and MMU notifier is synchronized. When it was odd, it means
> > > there's a reader we need to wait it to be even again then we are
> > > synchronized.
> > You just described a seqlock.
>
>
> Kind of, see my explanation below.
>
>
> >
> > We've been talking about providing this as some core service from mmu
> > notifiers because nearly every use of this API needs it.
>
>
> That would be very helpful.
>
>
> >
> > IMHO this gets the whole thing backwards, the common pattern is to
> > protect the 'shadow pte' data with a seqlock (usually open coded),
> > such that the mmu notififer side has the write side of that lock and
> > the read side is consumed by the thread accessing or updating the SPTE.
>
>
> Yes, I've considered something like that. But the problem is, mmu notifier
> (writer) need to wait for the vhost worker to finish the read before it can
> do things like setting dirty pages and unmapping page. It looks to me
> seqlock doesn't provide things like this.
The seqlock is usually used to prevent a 2nd thread from accessing the
VA while it is being changed by the mm. ie you use something seqlocky
instead of the ugly mmu_notifier_unregister/register cycle.
You are supposed to use something simple like a spinlock or mutex
inside the invalidate_range_start to serialized tear down of the SPTEs
with their accessors.
> write_seqcount_begin()
>
> map = vq->map[X]
>
> write or read through map->addr directly
>
> write_seqcount_end()
>
>
> There's no rmb() in write_seqcount_begin(), so map could be read before
> write_seqcount_begin(), but it looks to me now that this doesn't harm at
> all, maybe we can try this way.
That is because it is a write side lock, not a read lock. IIRC
seqlocks have weaker barriers because the write side needs to be
serialized in some other way.
The requirement I see is you need invalidate_range_start to block
until another thread exits its critical section (ie stops accessing
the SPTEs).
That is a spinlock/mutex.
You just can't invent a faster spinlock by open coding something with
barriers, it doesn't work.
Jason
^ permalink raw reply
* Re: [PATCH V2 4/9] vhost: reset invalidate_count in vhost_set_vring_num_addr()
From: Jason Gunthorpe @ 2019-07-31 19:32 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, kvm, virtualization, netdev, linux-kernel, linux-mm
In-Reply-To: <31ef9ed4-d74a-3454-a57d-fa843a3a802b@redhat.com>
On Wed, Jul 31, 2019 at 09:29:28PM +0800, Jason Wang wrote:
>
> On 2019/7/31 下午8:41, Jason Gunthorpe wrote:
> > On Wed, Jul 31, 2019 at 04:46:50AM -0400, Jason Wang wrote:
> > > The vhost_set_vring_num_addr() could be called in the middle of
> > > invalidate_range_start() and invalidate_range_end(). If we don't reset
> > > invalidate_count after the un-registering of MMU notifier, the
> > > invalidate_cont will run out of sync (e.g never reach zero). This will
> > > in fact disable the fast accessor path. Fixing by reset the count to
> > > zero.
> > >
> > > Reported-by: Michael S. Tsirkin <mst@redhat.com>
> > Did Michael report this as well?
>
>
> Correct me if I was wrong. I think it's point 4 described in
> https://lkml.org/lkml/2019/7/21/25.
I'm not sure what that is talking about
But this fixes what I described:
https://lkml.org/lkml/2019/7/22/554
Jason
^ permalink raw reply
* Re: [PATCH bpf 1/2] bpf: fix x64 JIT code generation for jmp to 1st insn
From: Song Liu @ 2019-07-31 19:35 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, netdev@vger.kernel.org,
bpf@vger.kernel.org, Kernel Team
In-Reply-To: <20190731013827.2445262-2-ast@kernel.org>
> On Jul 30, 2019, at 6:38 PM, Alexei Starovoitov <ast@kernel.org> wrote:
>
> Introduction of bounded loops exposed old bug in x64 JIT.
> JIT maintains the array of offsets to the end of all instructions to
> compute jmp offsets.
> addrs[0] - offset of the end of the 1st insn (that includes prologue).
> addrs[1] - offset of the end of the 2nd insn.
> JIT didn't keep the offset of the beginning of the 1st insn,
> since classic BPF didn't have backward jumps and valid extended BPF
> couldn't have a branch to 1st insn, because it didn't allow loops.
> With bounded loops it's possible to construct a valid program that
> jumps backwards to the 1st insn.
> Fix JIT by computing:
> addrs[0] - offset of the end of prologue == start of the 1st insn.
> addrs[1] - offset of the end of 1st insn.
>
> Reported-by: syzbot+35101610ff3e83119b1b@syzkaller.appspotmail.com
> Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
> Fixes: 0a14842f5a3c ("net: filter: Just In Time compiler for x86-64")
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
Do we need similar fix for x86_32?
Thanks,
Song
> ---
> arch/x86/net/bpf_jit_comp.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index eaaed5bfc4a4..a56c95805732 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -390,8 +390,9 @@ static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image,
>
> emit_prologue(&prog, bpf_prog->aux->stack_depth,
> bpf_prog_was_classic(bpf_prog));
> + addrs[0] = prog - temp;
>
> - for (i = 0; i < insn_cnt; i++, insn++) {
> + for (i = 1; i <= insn_cnt; i++, insn++) {
> const s32 imm32 = insn->imm;
> u32 dst_reg = insn->dst_reg;
> u32 src_reg = insn->src_reg;
> @@ -1105,7 +1106,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> extra_pass = true;
> goto skip_init_addrs;
> }
> - addrs = kmalloc_array(prog->len, sizeof(*addrs), GFP_KERNEL);
> + addrs = kmalloc_array(prog->len + 1, sizeof(*addrs), GFP_KERNEL);
> if (!addrs) {
> prog = orig_prog;
> goto out_addrs;
> @@ -1115,7 +1116,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> * Before first pass, make a rough estimation of addrs[]
> * each BPF instruction is translated to less than 64 bytes
> */
> - for (proglen = 0, i = 0; i < prog->len; i++) {
> + for (proglen = 0, i = 0; i <= prog->len; i++) {
> proglen += 64;
> addrs[i] = proglen;
> }
> --
> 2.20.0
>
^ permalink raw reply
* Re: [PATCH V2 4/9] vhost: reset invalidate_count in vhost_set_vring_num_addr()
From: Michael S. Tsirkin @ 2019-07-31 19:37 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jason Wang, kvm, virtualization, netdev, linux-kernel, linux-mm
In-Reply-To: <20190731193252.GH3946@ziepe.ca>
On Wed, Jul 31, 2019 at 04:32:52PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 31, 2019 at 09:29:28PM +0800, Jason Wang wrote:
> >
> > On 2019/7/31 下午8:41, Jason Gunthorpe wrote:
> > > On Wed, Jul 31, 2019 at 04:46:50AM -0400, Jason Wang wrote:
> > > > The vhost_set_vring_num_addr() could be called in the middle of
> > > > invalidate_range_start() and invalidate_range_end(). If we don't reset
> > > > invalidate_count after the un-registering of MMU notifier, the
> > > > invalidate_cont will run out of sync (e.g never reach zero). This will
> > > > in fact disable the fast accessor path. Fixing by reset the count to
> > > > zero.
> > > >
> > > > Reported-by: Michael S. Tsirkin <mst@redhat.com>
> > > Did Michael report this as well?
> >
> >
> > Correct me if I was wrong. I think it's point 4 described in
> > https://lkml.org/lkml/2019/7/21/25.
>
> I'm not sure what that is talking about
>
> But this fixes what I described:
>
> https://lkml.org/lkml/2019/7/22/554
>
> Jason
These are two reasons for a possible counter imbalance.
Unsurprisingly they are both fixed if you reset the counter to 0.
--
MST
^ permalink raw reply
* Re: [PATCH] net: bridge: Allow bridge to joing multicast groups
From: Allan W. Nielsen @ 2019-07-31 19:38 UTC (permalink / raw)
To: Andrew Lunn
Cc: Ido Schimmel, Nikolay Aleksandrov, Horatiu Vultur, roopa, davem,
bridge, netdev, linux-kernel
In-Reply-To: <20190731134550.GA23028@lunn.ch>
The 07/31/2019 15:45, Andrew Lunn wrote:
> > Here is how I see it:
> >
> > Teach the SW bridge about non-IP multicast addresses. Initially the switch
> > should forward all MAC multicast frames to the CPU. Today MDB rules can be
> > installed (either static or dynamic by IGMP), which limit the flooding of IPv4/6
> > multicast streams. In the same way, we should have a way to install a rule
> > (FDM/ or MDB) to limit the flooding of L2 multicast frames.
> >
> > If foreign interfaces (or br0 it self) is part of the destination list, then
> > traffic also needs to go to the CPU.
> >
> > By doing this, we can for explicitly configured dst mac address:
> > - limit the flooding on the on the SW bridge interfaces
> > - limit the flooding on the on the HW bridge interfaces
> > - prevent them to go to the CPU if they are not needed
> This is all very complex because of all the different corner cases. So
> i don't think we want a user API to do the CPU part, we want the
> network stack to do it. Otherwise the user is going to get is wrong,
> break their network, and then come running to the list for help.
Not sure I really understand what to conclude from this... Their are already
many ways the user can break it (tc has great hooks for that), and I not think
we can really prevent the user in configuring something that break stuff (but
we should not make it too easy either).
Anyway, Horatiu has come a long way in creating a (surprising simple) patch
which allow us to limit the flooding of L2-multicast. It is following the
guidance from Nikolay, it is using the MDB database, and I beleive it is well
aligned with the existing sw-bridge design.
I hope it will be ready tomorrow, then we can have a look at it and see if it is
any good.
> This also fits with how we do things in DSA. There is deliberately no
> user space concept for configuring the DSA CPU port. To user space,
> the switch is just a bunch of Linux interfaces. Everything to do with
> the CPU port is hidden away in the DSA core layer, the DSA drivers,
> and a little bit in the bridge.
Understood, but as far as I understand, in DSA you still have the br0 interface,
which kind-of represent the traffic going to the CPU (like in pure SW bridge,
and SwitchDev offloaded SW-bridge).
/Allan
^ permalink raw reply
* Re: [PATCH bpf 2/2] selftests/bpf: tests for jmp to 1st insn
From: Song Liu @ 2019-07-31 19:38 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, daniel@iogearbox.net, netdev@vger.kernel.org,
bpf@vger.kernel.org, Kernel Team
In-Reply-To: <20190731013827.2445262-3-ast@kernel.org>
> On Jul 30, 2019, at 6:38 PM, Alexei Starovoitov <ast@kernel.org> wrote:
>
> Add 2 tests that check JIT code generation to jumps to 1st insn.
> 1st test is similar to syzbot reproducer.
> The backwards branch is never taken at runtime.
> 2nd test has branch to 1st insn that executes.
> The test is written as two bpf functions, since it's not possible
> to construct valid single bpf program that jumps to 1st insn.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/testing/selftests/bpf/verifier/loops1.c | 28 +++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/verifier/loops1.c b/tools/testing/selftests/bpf/verifier/loops1.c
> index 5e980a5ab69d..1fc4e61e9f9f 100644
> --- a/tools/testing/selftests/bpf/verifier/loops1.c
> +++ b/tools/testing/selftests/bpf/verifier/loops1.c
> @@ -159,3 +159,31 @@
> .errstr = "loop detected",
> .prog_type = BPF_PROG_TYPE_TRACEPOINT,
> },
> +{
> + "not-taken loop with back jump to 1st insn",
> + .insns = {
> + BPF_MOV64_IMM(BPF_REG_0, 123),
> + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 4, -2),
> + BPF_EXIT_INSN(),
> + },
> + .result = ACCEPT,
> + .prog_type = BPF_PROG_TYPE_XDP,
> + .retval = 123,
> +},
> +{
> + "taken loop with back jump to 1st insn",
> + .insns = {
> + BPF_MOV64_IMM(BPF_REG_1, 10),
> + BPF_MOV64_IMM(BPF_REG_2, 0),
> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 1, 0, 1),
> + BPF_EXIT_INSN(),
> + BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_1),
> + BPF_ALU64_IMM(BPF_SUB, BPF_REG_1, 1),
> + BPF_JMP_IMM(BPF_JNE, BPF_REG_1, 0, -3),
> + BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
> + BPF_EXIT_INSN(),
> + },
> + .result = ACCEPT,
> + .prog_type = BPF_PROG_TYPE_XDP,
> + .retval = 55,
> +},
> --
> 2.20.0
>
^ permalink raw reply
* Re: [patch net-next v2 1/3] net: devlink: allow to change namespaces
From: David Ahern @ 2019-07-31 19:41 UTC (permalink / raw)
To: Jiri Pirko, Jakub Kicinski; +Cc: netdev, davem, sthemmin, mlxsw
In-Reply-To: <20190731192627.GB2324@nanopsycho>
On 7/31/19 1:26 PM, Jiri Pirko wrote:
> Wed, Jul 31, 2019 at 12:39:52AM CEST, jakub.kicinski@netronome.com wrote:
>> On Tue, 30 Jul 2019 10:57:32 +0200, Jiri Pirko wrote:
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> All devlink instances are created in init_net and stay there for a
>>> lifetime. Allow user to be able to move devlink instances into
>>> namespaces.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>
>> I'm no namespace expert, but seems reasonable, so FWIW:
>>
>> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>>
>> If I read things right we will only send the devlink instance
>> notification to other namespaces when it moves, but not
>> notifications for sub-objects like ports. Is the expectation
>> that the user space dumps the objects it cares about or will
>> the other notifications be added as needed (or option 3 - I
>> misread the code).
>
> You are correct. I plan to take care of the notifications of all objects
> in the follow-up patchset. But I can do it in this one if needed. Up to
> you.
>
seems like it should be a part of this one. If a devlink instance
changes namespaces, all of its associated resources should as well.
Also, seems like you are missing a 'can this devlink instance be moved'
check. e.g., what happens if a resource controller has been configured
for the devlink instance and it is moved to a namespace whose existing
config exceeds those limits?
^ permalink raw reply
* Re: [PATCH] net: usb: pegasus: fix improper read if get_registers() fail
From: Petko Manolov @ 2019-07-31 19:14 UTC (permalink / raw)
To: Denis Kirjanov; +Cc: davem, netdev
In-Reply-To: <20190731191039.gip2sttd2og2olx6@carbon>
On 19-07-31 22:10:39, Petko Manolov wrote:
> On 19-07-30 15:13:57, Denis Kirjanov wrote:
> > get_registers() may fail with -ENOMEM and in this
> > case we can read a garbage from the status variable tmp.
> >
> > Reported-by: syzbot+3499a83b2d062ae409d4@syzkaller.appspotmail.com
> > Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> > ---
> > drivers/net/usb/pegasus.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
> > index 6d25dea5ad4b..f7d117d80cfb 100644
> > --- a/drivers/net/usb/pegasus.c
> > +++ b/drivers/net/usb/pegasus.c
> > @@ -282,7 +282,7 @@ static void mdio_write(struct net_device *dev, int phy_id, int loc, int val)
> > static int read_eprom_word(pegasus_t *pegasus, __u8 index, __u16 *retdata)
> > {
> > int i;
> > - __u8 tmp;
> > + __u8 tmp = 0;
> > __le16 retdatai;
> > int ret;
>
> Unfortunately this patch does not fix anything. Even if get_registers() fail
> with -ENOMEM the "for" loop will cover for it and will exit only if the
> operation was successful or the device got disconnected. Please read the code
> carefully.
>
> So while the patch is harmless it isn't solving a problem.
Actually i am wrong - if "tmp" contains a random value it may accidentally have
the EPROM_DONE bit set.
Dave, please apply the patch.
thanks,
Petko
^ permalink raw reply
* Re: [PATCH] net: usb: pegasus: fix improper read if get_registers() fail
From: Petko Manolov @ 2019-07-31 19:10 UTC (permalink / raw)
To: Denis Kirjanov; +Cc: davem, netdev
In-Reply-To: <20190730131357.30697-1-dkirjanov@suse.com>
On 19-07-30 15:13:57, Denis Kirjanov wrote:
> get_registers() may fail with -ENOMEM and in this
> case we can read a garbage from the status variable tmp.
>
> Reported-by: syzbot+3499a83b2d062ae409d4@syzkaller.appspotmail.com
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> ---
> drivers/net/usb/pegasus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
> index 6d25dea5ad4b..f7d117d80cfb 100644
> --- a/drivers/net/usb/pegasus.c
> +++ b/drivers/net/usb/pegasus.c
> @@ -282,7 +282,7 @@ static void mdio_write(struct net_device *dev, int phy_id, int loc, int val)
> static int read_eprom_word(pegasus_t *pegasus, __u8 index, __u16 *retdata)
> {
> int i;
> - __u8 tmp;
> + __u8 tmp = 0;
> __le16 retdatai;
> int ret;
Unfortunately this patch does not fix anything. Even if get_registers() fail
with -ENOMEM the "for" loop will cover for it and will exit only if the
operation was successful or the device got disconnected. Please read the code
carefully.
So while the patch is harmless it isn't solving a problem.
cheers,
Petko
^ permalink raw reply
* Re: [patch net-next v2 1/3] net: devlink: allow to change namespaces
From: Jiri Pirko @ 2019-07-31 19:45 UTC (permalink / raw)
To: David Ahern; +Cc: Jakub Kicinski, netdev, davem, sthemmin, mlxsw
In-Reply-To: <c4f83be2-adee-1595-f241-de4c26ea55ca@gmail.com>
Wed, Jul 31, 2019 at 09:41:10PM CEST, dsahern@gmail.com wrote:
>On 7/31/19 1:26 PM, Jiri Pirko wrote:
>> Wed, Jul 31, 2019 at 12:39:52AM CEST, jakub.kicinski@netronome.com wrote:
>>> On Tue, 30 Jul 2019 10:57:32 +0200, Jiri Pirko wrote:
>>>> From: Jiri Pirko <jiri@mellanox.com>
>>>>
>>>> All devlink instances are created in init_net and stay there for a
>>>> lifetime. Allow user to be able to move devlink instances into
>>>> namespaces.
>>>>
>>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>>
>>> I'm no namespace expert, but seems reasonable, so FWIW:
>>>
>>> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>>>
>>> If I read things right we will only send the devlink instance
>>> notification to other namespaces when it moves, but not
>>> notifications for sub-objects like ports. Is the expectation
>>> that the user space dumps the objects it cares about or will
>>> the other notifications be added as needed (or option 3 - I
>>> misread the code).
>>
>> You are correct. I plan to take care of the notifications of all objects
>> in the follow-up patchset. But I can do it in this one if needed. Up to
>> you.
>>
>
>seems like it should be a part of this one. If a devlink instance
>changes namespaces, all of its associated resources should as well.
Okay. Will do.
>
>Also, seems like you are missing a 'can this devlink instance be moved'
I don't see why not.
>check. e.g., what happens if a resource controller has been configured
>for the devlink instance and it is moved to a namespace whose existing
>config exceeds those limits?
It's moved with all the values. The whole instance is moved.
^ permalink raw reply
* Re: [patch net-next v2 1/3] net: devlink: allow to change namespaces
From: David Ahern @ 2019-07-31 19:46 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Jakub Kicinski, netdev, davem, sthemmin, mlxsw
In-Reply-To: <20190731194502.GC2324@nanopsycho>
On 7/31/19 1:45 PM, Jiri Pirko wrote:
>> check. e.g., what happens if a resource controller has been configured
>> for the devlink instance and it is moved to a namespace whose existing
>> config exceeds those limits?
>
> It's moved with all the values. The whole instance is moved.
>
The values are moved, but the FIB in a namespace could already contain
more routes than the devlink instance allows.
^ permalink raw reply
* [PATCH 00/14] ARM: move lpc32xx and dove to multiplatform
From: Arnd Bergmann @ 2019-07-31 19:56 UTC (permalink / raw)
To: soc, linux-arm-kernel, Vladimir Zapolskiy, Sylvain Lemieux,
Russell King, Gregory Clement, Linus Walleij
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Greg Kroah-Hartman, Alan Stern, Guenter Roeck, linux-gpio, netdev,
linux-serial, linux-usb, linux-watchdog, Arnd Bergmann
I revisited some older patches here, getting two of the remaining
ARM platforms to build with ARCH_MULTIPLATFORM like most others do.
In case of lpc32xx, I created a new set of patches, which seemed
easier than digging out what I did for an older release many
years ago.
For dove, the patches are basically what I had proposed back in
2015 when all other ARMv6/ARMv7 machines became part of a single
kernel build. I don't know what the state is mach-dove support is,
compared to the DT based support in mach-mvebu for the same
hardware. If they are functionally the same, we could also just
remove mach-dove rather than applying my patches.
I also created patches to remove the w90x900 and ks8695 platforms
that seem to have lost their last users a few years ago.
I will post them separately, but plan to apply them in the same
branch for linux-5.4 if there are no objections.
Arnd
Arnd Bergmann (14):
usb: ohci-nxp: enable compile-testing
usb: udc: lpc32xx: allow compile-testing
watchdog: pnx4008_wdt: allow compile-testing
serial: lpc32xx_hs: allow compile-testing
gpio: lpc32xx: allow building on non-lpc32xx targets
net: lpc-enet: factor out iram access
net: lpc-enet: move phy setup into platform code
net: lpc-enet: allow compile testing
serial: lpc32xx: allow compile testing
ARM: lpc32xx: clean up header files
ARM: lpc32xx: allow multiplatform build
ARM: dove: clean up mach/*.h headers
ARM: orion/mvebu: unify debug-ll virtual addresses
ARM: dove: multiplatform support
arch/arm/Kconfig | 33 +---------
arch/arm/Kconfig.debug | 5 +-
arch/arm/configs/dove_defconfig | 2 +
arch/arm/configs/lpc32xx_defconfig | 1 +
arch/arm/mach-dove/Kconfig | 16 +++--
arch/arm/mach-dove/Makefile | 2 +
.../{include/mach => }/bridge-regs.h | 4 +-
arch/arm/mach-dove/cm-a510.c | 3 +-
arch/arm/mach-dove/common.c | 4 +-
arch/arm/mach-dove/dove-db-setup.c | 2 +-
arch/arm/mach-dove/{include/mach => }/dove.h | 14 ++---
arch/arm/mach-dove/include/mach/hardware.h | 19 ------
arch/arm/mach-dove/include/mach/uncompress.h | 36 -----------
arch/arm/mach-dove/irq.c | 5 +-
arch/arm/mach-dove/{include/mach => }/irqs.h | 2 -
arch/arm/mach-dove/mpp.c | 2 +-
arch/arm/mach-dove/pcie.c | 4 +-
arch/arm/mach-dove/{include/mach => }/pm.h | 4 +-
arch/arm/mach-lpc32xx/Kconfig | 11 ++++
arch/arm/mach-lpc32xx/common.c | 24 +++++--
arch/arm/mach-lpc32xx/common.h | 1 -
arch/arm/mach-lpc32xx/include/mach/board.h | 15 -----
.../mach-lpc32xx/include/mach/entry-macro.S | 28 ---------
arch/arm/mach-lpc32xx/include/mach/hardware.h | 25 --------
.../mach-lpc32xx/include/mach/uncompress.h | 50 ---------------
.../{include/mach/platform.h => lpc32xx.h} | 18 +++++-
arch/arm/mach-lpc32xx/pm.c | 3 +-
arch/arm/mach-lpc32xx/serial.c | 33 +++++++++-
arch/arm/mach-lpc32xx/suspend.S | 3 +-
arch/arm/mach-mv78xx0/mv78xx0.h | 4 +-
arch/arm/mach-orion5x/orion5x.h | 4 +-
drivers/gpio/Kconfig | 8 +++
drivers/gpio/Makefile | 2 +-
drivers/gpio/gpio-lpc32xx.c | 63 ++++++++++++-------
drivers/net/ethernet/nxp/Kconfig | 2 +-
drivers/net/ethernet/nxp/lpc_eth.c | 30 +++------
drivers/tty/serial/Kconfig | 3 +-
drivers/tty/serial/lpc32xx_hs.c | 37 ++---------
drivers/usb/gadget/udc/Kconfig | 3 +-
drivers/usb/gadget/udc/lpc32xx_udc.c | 2 -
drivers/usb/host/Kconfig | 3 +-
drivers/usb/host/ohci-nxp.c | 25 +++++---
drivers/watchdog/Kconfig | 2 +-
drivers/watchdog/pnx4008_wdt.c | 1 -
include/linux/soc/nxp/lpc32xx-misc.h | 33 ++++++++++
45 files changed, 246 insertions(+), 345 deletions(-)
rename arch/arm/mach-dove/{include/mach => }/bridge-regs.h (96%)
rename arch/arm/mach-dove/{include/mach => }/dove.h (95%)
delete mode 100644 arch/arm/mach-dove/include/mach/hardware.h
delete mode 100644 arch/arm/mach-dove/include/mach/uncompress.h
rename arch/arm/mach-dove/{include/mach => }/irqs.h (98%)
rename arch/arm/mach-dove/{include/mach => }/pm.h (97%)
create mode 100644 arch/arm/mach-lpc32xx/Kconfig
delete mode 100644 arch/arm/mach-lpc32xx/include/mach/board.h
delete mode 100644 arch/arm/mach-lpc32xx/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-lpc32xx/include/mach/hardware.h
delete mode 100644 arch/arm/mach-lpc32xx/include/mach/uncompress.h
rename arch/arm/mach-lpc32xx/{include/mach/platform.h => lpc32xx.h} (98%)
create mode 100644 include/linux/soc/nxp/lpc32xx-misc.h
--
2.20.0
^ permalink raw reply
* Re: [patch net-next v2 1/3] net: devlink: allow to change namespaces
From: David Ahern @ 2019-07-31 19:58 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Jakub Kicinski, netdev, davem, sthemmin, mlxsw
In-Reply-To: <087f584d-06c5-f4b9-722b-ccb72ce0e5de@gmail.com>
On 7/31/19 1:46 PM, David Ahern wrote:
> On 7/31/19 1:45 PM, Jiri Pirko wrote:
>>> check. e.g., what happens if a resource controller has been configured
>>> for the devlink instance and it is moved to a namespace whose existing
>>> config exceeds those limits?
>>
>> It's moved with all the values. The whole instance is moved.
>>
>
> The values are moved, but the FIB in a namespace could already contain
> more routes than the devlink instance allows.
>
From a quick test your recent refactoring to netdevsim broke the
resource controller. It was, and is intended to be, per network namespace.
^ permalink raw reply
* [PATCH 01/14] usb: ohci-nxp: enable compile-testing
From: Arnd Bergmann @ 2019-07-31 19:56 UTC (permalink / raw)
To: soc, linux-arm-kernel, Vladimir Zapolskiy, Sylvain Lemieux,
Russell King, Gregory Clement, Linus Walleij, Greg Kroah-Hartman,
Alan Stern
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Guenter Roeck, linux-gpio, netdev, linux-serial, linux-usb,
linux-watchdog, Arnd Bergmann, linux-kernel
In-Reply-To: <20190731195713.3150463-1-arnd@arndb.de>
The driver hardcodes a hardware I/O address the way one should
generally not do, and this prevents both compile-testing, and
moving the platform to CONFIG_ARCH_MULTIPLATFORM.
Change the code to be independent of the machine headers
to allow those two. Removing the hardcoded address would
be hard and is not necessary, so leave that in place for now.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/usb/host/Kconfig | 3 ++-
drivers/usb/host/ohci-nxp.c | 25 ++++++++++++++++++-------
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 40b5de597112..73d233d3bf4d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -441,7 +441,8 @@ config USB_OHCI_HCD_S3C2410
config USB_OHCI_HCD_LPC32XX
tristate "Support for LPC on-chip OHCI USB controller"
- depends on USB_OHCI_HCD && ARCH_LPC32XX
+ depends on USB_OHCI_HCD
+ depends on ARCH_LPC32XX || COMPILE_TEST
depends on USB_ISP1301
default y
---help---
diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index f5f532601092..c561881d0e79 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -29,10 +29,7 @@
#include "ohci.h"
-#include <mach/hardware.h>
-
#define USB_CONFIG_BASE 0x31020000
-#define USB_OTG_STAT_CONTROL IO_ADDRESS(USB_CONFIG_BASE + 0x110)
/* USB_OTG_STAT_CONTROL bit defines */
#define TRANSPARENT_I2C_EN (1 << 7)
@@ -122,19 +119,33 @@ static inline void isp1301_vbus_off(void)
static void ohci_nxp_start_hc(void)
{
- unsigned long tmp = __raw_readl(USB_OTG_STAT_CONTROL) | HOST_EN;
+ void __iomem *usb_otg_stat_control = ioremap(USB_CONFIG_BASE + 0x110, 4);
+ unsigned long tmp;
+
+ if (WARN_ON(!usb_otg_stat_control))
+ return;
+
+ tmp = __raw_readl(usb_otg_stat_control) | HOST_EN;
- __raw_writel(tmp, USB_OTG_STAT_CONTROL);
+ __raw_writel(tmp, usb_otg_stat_control);
isp1301_vbus_on();
+
+ iounmap(usb_otg_stat_control);
}
static void ohci_nxp_stop_hc(void)
{
+ void __iomem *usb_otg_stat_control = ioremap(USB_CONFIG_BASE + 0x110, 4);
unsigned long tmp;
+ if (WARN_ON(!usb_otg_stat_control))
+ return;
+
isp1301_vbus_off();
- tmp = __raw_readl(USB_OTG_STAT_CONTROL) & ~HOST_EN;
- __raw_writel(tmp, USB_OTG_STAT_CONTROL);
+ tmp = __raw_readl(usb_otg_stat_control) & ~HOST_EN;
+ __raw_writel(tmp, usb_otg_stat_control);
+
+ iounmap(usb_otg_stat_control);
}
static int ohci_hcd_nxp_probe(struct platform_device *pdev)
--
2.20.0
^ permalink raw reply related
* [PATCH 02/14] usb: udc: lpc32xx: allow compile-testing
From: Arnd Bergmann @ 2019-07-31 19:56 UTC (permalink / raw)
To: soc, linux-arm-kernel, Vladimir Zapolskiy, Sylvain Lemieux,
Russell King, Gregory Clement, Linus Walleij, Felipe Balbi,
Greg Kroah-Hartman
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Alan Stern, Guenter Roeck, linux-gpio, netdev, linux-serial,
linux-usb, linux-watchdog, Arnd Bergmann, Alexandre Belloni,
linux-kernel
In-Reply-To: <20190731195713.3150463-1-arnd@arndb.de>
The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/usb/gadget/udc/Kconfig | 3 ++-
drivers/usb/gadget/udc/lpc32xx_udc.c | 2 --
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index ef0259a950ba..d354036ff6c8 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -45,7 +45,8 @@ config USB_AT91
config USB_LPC32XX
tristate "LPC32XX USB Peripheral Controller"
- depends on ARCH_LPC32XX && I2C
+ depends on ARCH_LPC32XX || COMPILE_TEST
+ depends on I2C
select USB_ISP1301
help
This option selects the USB device controller in the LPC32xx SoC.
diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c
index 5f1b14f3e5a0..4d8847988a50 100644
--- a/drivers/usb/gadget/udc/lpc32xx_udc.c
+++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
@@ -35,8 +35,6 @@
#include <linux/seq_file.h>
#endif
-#include <mach/hardware.h>
-
/*
* USB device configuration structure
*/
--
2.20.0
^ permalink raw reply related
* [PATCH 03/14] watchdog: pnx4008_wdt: allow compile-testing
From: Arnd Bergmann @ 2019-07-31 19:56 UTC (permalink / raw)
To: soc, linux-arm-kernel, Vladimir Zapolskiy, Sylvain Lemieux,
Russell King, Gregory Clement, Linus Walleij, Wim Van Sebroeck,
Guenter Roeck
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Greg Kroah-Hartman, Alan Stern, linux-gpio, netdev, linux-serial,
linux-usb, linux-watchdog, Arnd Bergmann, linux-kernel
In-Reply-To: <20190731195713.3150463-1-arnd@arndb.de>
The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/watchdog/Kconfig | 2 +-
drivers/watchdog/pnx4008_wdt.c | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8188963a405b..a45f9e3e442b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -551,7 +551,7 @@ config OMAP_WATCHDOG
config PNX4008_WATCHDOG
tristate "LPC32XX Watchdog"
- depends on ARCH_LPC32XX
+ depends on ARCH_LPC32XX || COMPILE_TEST
select WATCHDOG_CORE
help
Say Y here if to include support for the watchdog timer
diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 7b446b696f2b..e0ea133c1690 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -30,7 +30,6 @@
#include <linux/of.h>
#include <linux/delay.h>
#include <linux/reboot.h>
-#include <mach/hardware.h>
/* WatchDog Timer - Chapter 23 Page 207 */
--
2.20.0
^ permalink raw reply related
* [PATCH 04/14] serial: lpc32xx_hs: allow compile-testing
From: Arnd Bergmann @ 2019-07-31 19:56 UTC (permalink / raw)
To: soc, linux-arm-kernel, Vladimir Zapolskiy, Sylvain Lemieux,
Russell King, Gregory Clement, Linus Walleij, Greg Kroah-Hartman,
Jiri Slaby
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Alan Stern, Guenter Roeck, linux-gpio, netdev, linux-serial,
linux-usb, linux-watchdog, Arnd Bergmann, linux-kernel
In-Reply-To: <20190731195713.3150463-1-arnd@arndb.de>
The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/tty/serial/Kconfig | 3 ++-
drivers/tty/serial/lpc32xx_hs.c | 2 --
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3083dbae35f7..518aac902e4b 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -739,7 +739,8 @@ config SERIAL_PNX8XXX_CONSOLE
config SERIAL_HS_LPC32XX
tristate "LPC32XX high speed serial port support"
- depends on ARCH_LPC32XX && OF
+ depends on ARCH_LPC32XX || COMPILE_TEST
+ depends on OF
select SERIAL_CORE
help
Support for the LPC32XX high speed serial ports (up to 900kbps).
diff --git a/drivers/tty/serial/lpc32xx_hs.c b/drivers/tty/serial/lpc32xx_hs.c
index f4e27d0ad947..7f14cd8fac47 100644
--- a/drivers/tty/serial/lpc32xx_hs.c
+++ b/drivers/tty/serial/lpc32xx_hs.c
@@ -25,8 +25,6 @@
#include <linux/irq.h>
#include <linux/gpio.h>
#include <linux/of.h>
-#include <mach/platform.h>
-#include <mach/hardware.h>
/*
* High Speed UART register offsets
--
2.20.0
^ permalink raw reply related
* [PATCH 05/14] gpio: lpc32xx: allow building on non-lpc32xx targets
From: Arnd Bergmann @ 2019-07-31 19:56 UTC (permalink / raw)
To: soc, linux-arm-kernel, Vladimir Zapolskiy, Sylvain Lemieux,
Russell King, Gregory Clement, Linus Walleij, Bartosz Golaszewski
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Greg Kroah-Hartman, Alan Stern, Guenter Roeck, linux-gpio, netdev,
linux-serial, linux-usb, linux-watchdog, Arnd Bergmann, Lee Jones,
linux-kernel
In-Reply-To: <20190731195713.3150463-1-arnd@arndb.de>
The driver uses hardwire MMIO addresses instead of the data
that is passed in device tree. Change it over to only
hardcode the register offset values and allow compile-testing.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/gpio/Kconfig | 8 +++++
drivers/gpio/Makefile | 2 +-
drivers/gpio/gpio-lpc32xx.c | 63 ++++++++++++++++++++++++-------------
3 files changed, 50 insertions(+), 23 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bb13c266c329..ae86ee963eae 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -311,6 +311,14 @@ config GPIO_LPC18XX
Select this option to enable GPIO driver for
NXP LPC18XX/43XX devices.
+config GPIO_LPC32XX
+ tristate "NXP LPC32XX GPIO support"
+ default ARCH_LPC32XX
+ depends on OF_GPIO && (ARCH_LPC32XX || COMPILE_TEST)
+ help
+ Select this option to enable GPIO driver for
+ NXP LPC32XX devices.
+
config GPIO_LYNXPOINT
tristate "Intel Lynxpoint GPIO support"
depends on ACPI && X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a4e91175c708..87d659ae95eb 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -74,7 +74,7 @@ obj-$(CONFIG_GPIO_LP3943) += gpio-lp3943.o
obj-$(CONFIG_GPIO_LP873X) += gpio-lp873x.o
obj-$(CONFIG_GPIO_LP87565) += gpio-lp87565.o
obj-$(CONFIG_GPIO_LPC18XX) += gpio-lpc18xx.o
-obj-$(CONFIG_ARCH_LPC32XX) += gpio-lpc32xx.o
+obj-$(CONFIG_GPIO_LPC32XX) += gpio-lpc32xx.o
obj-$(CONFIG_GPIO_LYNXPOINT) += gpio-lynxpoint.o
obj-$(CONFIG_GPIO_MADERA) += gpio-madera.o
obj-$(CONFIG_GPIO_MAX3191X) += gpio-max3191x.o
diff --git a/drivers/gpio/gpio-lpc32xx.c b/drivers/gpio/gpio-lpc32xx.c
index 24885b3db3d5..548f7cb69386 100644
--- a/drivers/gpio/gpio-lpc32xx.c
+++ b/drivers/gpio/gpio-lpc32xx.c
@@ -16,8 +16,7 @@
#include <linux/platform_device.h>
#include <linux/module.h>
-#include <mach/hardware.h>
-#include <mach/platform.h>
+#define _GPREG(x) (x)
#define LPC32XX_GPIO_P3_INP_STATE _GPREG(0x000)
#define LPC32XX_GPIO_P3_OUTP_SET _GPREG(0x004)
@@ -72,12 +71,12 @@
#define LPC32XX_GPO_P3_GRP (LPC32XX_GPI_P3_GRP + LPC32XX_GPI_P3_MAX)
struct gpio_regs {
- void __iomem *inp_state;
- void __iomem *outp_state;
- void __iomem *outp_set;
- void __iomem *outp_clr;
- void __iomem *dir_set;
- void __iomem *dir_clr;
+ unsigned long inp_state;
+ unsigned long outp_state;
+ unsigned long outp_set;
+ unsigned long outp_clr;
+ unsigned long dir_set;
+ unsigned long dir_clr;
};
/*
@@ -167,14 +166,26 @@ struct lpc32xx_gpio_chip {
struct gpio_regs *gpio_grp;
};
+void __iomem *gpio_reg_base;
+
+static inline u32 gpreg_read(unsigned long offset)
+{
+ return __raw_readl(gpio_reg_base + offset);
+}
+
+static inline void gpreg_write(u32 val, unsigned long offset)
+{
+ __raw_writel(val, gpio_reg_base + offset);
+}
+
static void __set_gpio_dir_p012(struct lpc32xx_gpio_chip *group,
unsigned pin, int input)
{
if (input)
- __raw_writel(GPIO012_PIN_TO_BIT(pin),
+ gpreg_write(GPIO012_PIN_TO_BIT(pin),
group->gpio_grp->dir_clr);
else
- __raw_writel(GPIO012_PIN_TO_BIT(pin),
+ gpreg_write(GPIO012_PIN_TO_BIT(pin),
group->gpio_grp->dir_set);
}
@@ -184,19 +195,19 @@ static void __set_gpio_dir_p3(struct lpc32xx_gpio_chip *group,
u32 u = GPIO3_PIN_TO_BIT(pin);
if (input)
- __raw_writel(u, group->gpio_grp->dir_clr);
+ gpreg_write(u, group->gpio_grp->dir_clr);
else
- __raw_writel(u, group->gpio_grp->dir_set);
+ gpreg_write(u, group->gpio_grp->dir_set);
}
static void __set_gpio_level_p012(struct lpc32xx_gpio_chip *group,
unsigned pin, int high)
{
if (high)
- __raw_writel(GPIO012_PIN_TO_BIT(pin),
+ gpreg_write(GPIO012_PIN_TO_BIT(pin),
group->gpio_grp->outp_set);
else
- __raw_writel(GPIO012_PIN_TO_BIT(pin),
+ gpreg_write(GPIO012_PIN_TO_BIT(pin),
group->gpio_grp->outp_clr);
}
@@ -206,31 +217,31 @@ static void __set_gpio_level_p3(struct lpc32xx_gpio_chip *group,
u32 u = GPIO3_PIN_TO_BIT(pin);
if (high)
- __raw_writel(u, group->gpio_grp->outp_set);
+ gpreg_write(u, group->gpio_grp->outp_set);
else
- __raw_writel(u, group->gpio_grp->outp_clr);
+ gpreg_write(u, group->gpio_grp->outp_clr);
}
static void __set_gpo_level_p3(struct lpc32xx_gpio_chip *group,
unsigned pin, int high)
{
if (high)
- __raw_writel(GPO3_PIN_TO_BIT(pin), group->gpio_grp->outp_set);
+ gpreg_write(GPO3_PIN_TO_BIT(pin), group->gpio_grp->outp_set);
else
- __raw_writel(GPO3_PIN_TO_BIT(pin), group->gpio_grp->outp_clr);
+ gpreg_write(GPO3_PIN_TO_BIT(pin), group->gpio_grp->outp_clr);
}
static int __get_gpio_state_p012(struct lpc32xx_gpio_chip *group,
unsigned pin)
{
- return GPIO012_PIN_IN_SEL(__raw_readl(group->gpio_grp->inp_state),
+ return GPIO012_PIN_IN_SEL(gpreg_read(group->gpio_grp->inp_state),
pin);
}
static int __get_gpio_state_p3(struct lpc32xx_gpio_chip *group,
unsigned pin)
{
- int state = __raw_readl(group->gpio_grp->inp_state);
+ int state = gpreg_read(group->gpio_grp->inp_state);
/*
* P3 GPIO pin input mapping is not contiguous, GPIOP3-0..4 is mapped
@@ -242,13 +253,13 @@ static int __get_gpio_state_p3(struct lpc32xx_gpio_chip *group,
static int __get_gpi_state_p3(struct lpc32xx_gpio_chip *group,
unsigned pin)
{
- return GPI3_PIN_IN_SEL(__raw_readl(group->gpio_grp->inp_state), pin);
+ return GPI3_PIN_IN_SEL(gpreg_read(group->gpio_grp->inp_state), pin);
}
static int __get_gpo_state_p3(struct lpc32xx_gpio_chip *group,
unsigned pin)
{
- return GPO3_PIN_IN_SEL(__raw_readl(group->gpio_grp->outp_state), pin);
+ return GPO3_PIN_IN_SEL(gpreg_read(group->gpio_grp->outp_state), pin);
}
/*
@@ -498,6 +509,10 @@ static int lpc32xx_gpio_probe(struct platform_device *pdev)
{
int i;
+ gpio_reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (gpio_reg_base)
+ return -ENXIO;
+
for (i = 0; i < ARRAY_SIZE(lpc32xx_gpiochip); i++) {
if (pdev->dev.of_node) {
lpc32xx_gpiochip[i].chip.of_xlate = lpc32xx_of_xlate;
@@ -527,3 +542,7 @@ static struct platform_driver lpc32xx_gpio_driver = {
};
module_platform_driver(lpc32xx_gpio_driver);
+
+MODULE_AUTHOR("Kevin Wells <kevin.wells@nxp.com>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("GPIO driver for LPC32xx SoC");
--
2.20.0
^ permalink raw reply related
* [PATCH 06/14] net: lpc-enet: factor out iram access
From: Arnd Bergmann @ 2019-07-31 19:56 UTC (permalink / raw)
To: soc, linux-arm-kernel, Vladimir Zapolskiy, Sylvain Lemieux,
Russell King, Gregory Clement, Linus Walleij
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Greg Kroah-Hartman, Alan Stern, Guenter Roeck, linux-gpio, netdev,
linux-serial, linux-usb, linux-watchdog, Arnd Bergmann,
linux-kernel
In-Reply-To: <20190731195713.3150463-1-arnd@arndb.de>
The lpc_eth driver uses a platform specific method to find
the internal sram. This prevents building it on other machines.
Rework to only use one function call and keep the other platform
internals where they belong. Ideally this would look up the
sram location from DT, but as this is a rarely used driver,
I want to keep the modifications to a minimum.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-lpc32xx/common.c | 9 ++++++--
arch/arm/mach-lpc32xx/common.h | 1 -
arch/arm/mach-lpc32xx/include/mach/board.h | 15 --------------
drivers/net/ethernet/nxp/lpc_eth.c | 17 ++++++++-------
include/linux/soc/nxp/lpc32xx-misc.h | 24 ++++++++++++++++++++++
5 files changed, 39 insertions(+), 27 deletions(-)
delete mode 100644 arch/arm/mach-lpc32xx/include/mach/board.h
create mode 100644 include/linux/soc/nxp/lpc32xx-misc.h
diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index 5b71b4fab2cd..f648324d5fb4 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -8,6 +8,7 @@
*/
#include <linux/init.h>
+#include <linux/soc/nxp/lpc32xx-misc.h>
#include <asm/mach/map.h>
#include <asm/system_info.h>
@@ -32,7 +33,7 @@ void lpc32xx_get_uid(u32 devid[4])
*/
#define LPC32XX_IRAM_BANK_SIZE SZ_128K
static u32 iram_size;
-u32 lpc32xx_return_iram_size(void)
+u32 lpc32xx_return_iram(void __iomem **mapbase, dma_addr_t *dmaaddr)
{
if (iram_size == 0) {
u32 savedval1, savedval2;
@@ -53,10 +54,14 @@ u32 lpc32xx_return_iram_size(void)
} else
iram_size = LPC32XX_IRAM_BANK_SIZE * 2;
}
+ if (dmaaddr)
+ *dmaaddr = LPC32XX_IRAM_BASE;
+ if (mapbase)
+ *mapbase = io_p2v(LPC32XX_IRAM_BASE);
return iram_size;
}
-EXPORT_SYMBOL_GPL(lpc32xx_return_iram_size);
+EXPORT_SYMBOL_GPL(lpc32xx_return_iram);
static struct map_desc lpc32xx_io_desc[] __initdata = {
{
diff --git a/arch/arm/mach-lpc32xx/common.h b/arch/arm/mach-lpc32xx/common.h
index 8e597ce48a73..32f0ad217807 100644
--- a/arch/arm/mach-lpc32xx/common.h
+++ b/arch/arm/mach-lpc32xx/common.h
@@ -23,7 +23,6 @@ extern void __init lpc32xx_serial_init(void);
*/
extern void lpc32xx_get_uid(u32 devid[4]);
-extern u32 lpc32xx_return_iram_size(void);
/*
* Pointers used for sizing and copying suspend function data
*/
diff --git a/arch/arm/mach-lpc32xx/include/mach/board.h b/arch/arm/mach-lpc32xx/include/mach/board.h
deleted file mode 100644
index 476513d970a4..000000000000
--- a/arch/arm/mach-lpc32xx/include/mach/board.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * arm/arch/mach-lpc32xx/include/mach/board.h
- *
- * Author: Kevin Wells <kevin.wells@nxp.com>
- *
- * Copyright (C) 2010 NXP Semiconductors
- */
-
-#ifndef __ASM_ARCH_BOARD_H
-#define __ASM_ARCH_BOARD_H
-
-extern u32 lpc32xx_return_iram_size(void);
-
-#endif /* __ASM_ARCH_BOARD_H */
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index f7e11f1b0426..bcdd0adcfb0c 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -18,8 +18,8 @@
#include <linux/phy.h>
#include <linux/platform_device.h>
#include <linux/spinlock.h>
+#include <linux/soc/nxp/lpc32xx-misc.h>
-#include <mach/board.h>
#include <mach/hardware.h>
#include <mach/platform.h>
@@ -1311,16 +1311,15 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
/* Get size of DMA buffers/descriptors region */
pldat->dma_buff_size = (ENET_TX_DESC + ENET_RX_DESC) * (ENET_MAXF_SIZE +
sizeof(struct txrx_desc_t) + sizeof(struct rx_status_t));
- pldat->dma_buff_base_v = 0;
if (use_iram_for_net(dev)) {
- dma_handle = LPC32XX_IRAM_BASE;
- if (pldat->dma_buff_size <= lpc32xx_return_iram_size())
- pldat->dma_buff_base_v =
- io_p2v(LPC32XX_IRAM_BASE);
- else
+ if (pldat->dma_buff_size >
+ lpc32xx_return_iram(&pldat->dma_buff_base_v, &dma_handle)) {
+ pldat->dma_buff_base_v = NULL;
+ pldat->dma_buff_size = 0;
netdev_err(ndev,
"IRAM not big enough for net buffers, using SDRAM instead.\n");
+ }
}
if (pldat->dma_buff_base_v == 0) {
@@ -1409,7 +1408,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
unregister_netdev(ndev);
err_out_dma_unmap:
if (!use_iram_for_net(dev) ||
- pldat->dma_buff_size > lpc32xx_return_iram_size())
+ pldat->dma_buff_size > lpc32xx_return_iram(NULL, NULL))
dma_free_coherent(dev, pldat->dma_buff_size,
pldat->dma_buff_base_v,
pldat->dma_buff_base_p);
@@ -1436,7 +1435,7 @@ static int lpc_eth_drv_remove(struct platform_device *pdev)
unregister_netdev(ndev);
if (!use_iram_for_net(&pldat->pdev->dev) ||
- pldat->dma_buff_size > lpc32xx_return_iram_size())
+ pldat->dma_buff_size > lpc32xx_return_iram(NULL, NULL))
dma_free_coherent(&pldat->pdev->dev, pldat->dma_buff_size,
pldat->dma_buff_base_v,
pldat->dma_buff_base_p);
diff --git a/include/linux/soc/nxp/lpc32xx-misc.h b/include/linux/soc/nxp/lpc32xx-misc.h
new file mode 100644
index 000000000000..f232e1a1bcdc
--- /dev/null
+++ b/include/linux/soc/nxp/lpc32xx-misc.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Author: Kevin Wells <kevin.wells@nxp.com>
+ *
+ * Copyright (C) 2010 NXP Semiconductors
+ */
+
+#ifndef __SOC_LPC32XX_MISC_H
+#define __SOC_LPC32XX_MISC_H
+
+#include <linux/types.h>
+
+#ifdef CONFIG_ARCH_LPC32XX
+extern u32 lpc32xx_return_iram(void __iomem **mapbase, dma_addr_t *dmaaddr);
+#else
+static inline u32 lpc32xx_return_iram(void __iomem **mapbase, dma_addr_t *dmaaddr)
+{
+ *mapbase = NULL;
+ *dmaaddr = 0;
+ return 0;
+}
+#endif
+
+#endif /* __SOC_LPC32XX_MISC_H */
--
2.20.0
^ 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