* Re: Question on rhashtable in worst-case scenario.
From: Herbert Xu @ 2016-04-01 0:46 UTC (permalink / raw)
To: Johannes Berg
Cc: Ben Greear, David Miller, linux-kernel, linux-wireless, netdev,
tgraf
In-Reply-To: <1459438199.4576.26.camel@sipsolutions.net>
On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote:
>
> Does removing this completely disable the "-EEXIST" error? I can't say
> I fully understand the elasticity stuff in __rhashtable_insert_fast().
What EEXIST error are you talking about? The only one that can be
returned on insertion is if you're explicitly checking for dups
which clearly can't be the case for you.
If you're talking about the EEXIST error due to a rehash then it is
completely hidden from you by rhashtable_insert_rehash.
If you actually meant EBUSY then yes this should prevent it from
occurring, unless your chain-length exceeds 2^32.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Eric Dumazet @ 2016-04-01 1:19 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: davem, netdev, sasha.levin, daniel, alexei.starovoitov, mkubecek
In-Reply-To: <56FDBF0E.8020309@stressinduktion.org>
On Fri, 2016-04-01 at 02:21 +0200, Hannes Frederic Sowa wrote:
>
> [ 31.064029] ===============================
> [ 31.064030] [ INFO: suspicious RCU usage. ]
> [ 31.064032] 4.5.0+ #13 Not tainted
> [ 31.064033] -------------------------------
> [ 31.064034] include/net/sock.h:1594 suspicious
> rcu_dereference_check() usage!
> [ 31.064035]
> other info that might help us debug this:
>
> [ 31.064041]
> rcu_scheduler_active = 1, debug_locks = 1
> [ 31.064042] no locks held by ssh/817.
> [ 31.064043]
> stack backtrace:
> [ 31.064045] CPU: 0 PID: 817 Comm: ssh Not tainted 4.5.0+ #13
> [ 31.064046] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.8.2-20150714_191134- 04/01/2014
> [ 31.064047] 0000000000000286 000000006730b46b ffff8800badf7bd0
> ffffffff81442b33
> [ 31.064050] ffff8800b8c78000 0000000000000001 ffff8800badf7c00
> ffffffff8110ae75
> [ 31.064052] ffff880035ea2f00 ffff8800b8e28000 0000000000000003
> 00000000000004c4
> [ 31.064054] Call Trace:
> [ 31.064058] [<ffffffff81442b33>] dump_stack+0x85/0xc2
> [ 31.064062] [<ffffffff8110ae75>] lockdep_rcu_suspicious+0xc5/0x100
> [ 31.064064] [<ffffffff8173bf57>] __sk_dst_check+0x77/0xb0
> [ 31.064066] [<ffffffff8182e502>] inet6_sk_rebuild_header+0x52/0x300
> [ 31.064068] [<ffffffff813bb61e>] ? selinux_skb_peerlbl_sid+0x5e/0xa0
> [ 31.064070] [<ffffffff813bb69e>] ?
> selinux_inet_conn_established+0x3e/0x40
> [ 31.064072] [<ffffffff817c2bad>] tcp_finish_connect+0x4d/0x270
> [ 31.064074] [<ffffffff817c33f7>] tcp_rcv_state_process+0x627/0xe40
> [ 31.064076] [<ffffffff81866584>] tcp_v6_do_rcv+0xd4/0x410
> [ 31.064078] [<ffffffff8173bc65>] release_sock+0x85/0x1c0
> [ 31.064079] [<ffffffff817e9983>] __inet_stream_connect+0x1c3/0x340
> [ 31.064081] [<ffffffff8173b089>] ? lock_sock_nested+0x49/0xb0
> [ 31.064083] [<ffffffff81100270>] ? abort_exclusive_wait+0xb0/0xb0
> [ 31.064084] [<ffffffff817e9b38>] inet_stream_connect+0x38/0x50
> [ 31.064086] [<ffffffff8173794f>] SYSC_connect+0xcf/0xf0
> [ 31.064088] [<ffffffff8110d069>] ? trace_hardirqs_on_caller+0x129/0x1b0
> [ 31.064090] [<ffffffff8100301b>] ? trace_hardirqs_on_thunk+0x1b/0x1d
> [ 31.064091] [<ffffffff8173854e>] SyS_connect+0xe/0x10
> [ 31.064094] [<ffffffff818a0e7c>] entry_SYSCALL_64_fastpath+0x1f/0xbd
>
> Bye,
> Hannes
Thanks.
As you can see, release_sock() messes badly lockdep (once your other
patches are in )
Once we properly fix release_sock() and/or __release_sock(), all these
false positives disappear.
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Eric Dumazet @ 2016-04-01 1:23 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: davem, netdev, sasha.levin, daniel, alexei.starovoitov, mkubecek
In-Reply-To: <56FDC143.5060507@stressinduktion.org>
On Fri, 2016-04-01 at 02:30 +0200, Hannes Frederic Sowa wrote:
> I fixed this one, I wait with review a bit and collapse some of the
> newer fixes into one and check and repost again tomorrow.
No change should be needed in TCP, once net/core/sock.c is fixed.
When someone fixes a lockdep issue, it should be mandatory to include in
the changelog the lockdep splat, so that we can double check.
Thanks.
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Hannes Frederic Sowa @ 2016-04-01 1:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, netdev, sasha.levin, daniel, alexei.starovoitov, mkubecek
In-Reply-To: <1459473592.6473.243.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
> Thanks.
>
> As you can see, release_sock() messes badly lockdep (once your other
> patches are in )
>
> Once we properly fix release_sock() and/or __release_sock(), all these
> false positives disappear.
This was a loopback connection. I need to study release_sock and
__release_sock more as I cannot currently see an issue with the lockdep
handling.
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Hannes Frederic Sowa @ 2016-04-01 1:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, netdev, sasha.levin, daniel, alexei.starovoitov, mkubecek
In-Reply-To: <1459473790.6473.247.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Apr 1, 2016, at 03:23, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 02:30 +0200, Hannes Frederic Sowa wrote:
>
> > I fixed this one, I wait with review a bit and collapse some of the
> > newer fixes into one and check and repost again tomorrow.
>
> No change should be needed in TCP, once net/core/sock.c is fixed.
>
> When someone fixes a lockdep issue, it should be mandatory to include in
> the changelog the lockdep splat, so that we can double check.
Yup, will do that. Every change will be a single patch with lockdep
report.
Thank you,
Hannes
^ permalink raw reply
* RE: [PATCH] net: fec: stop the "rcv is not +last, " error messages
From: Fugang Duan @ 2016-04-01 1:37 UTC (permalink / raw)
To: Fabio Estevam; +Cc: Greg Ungerer, Troy Kisky, netdev@vger.kernel.org
In-Reply-To: <CAOMZO5AfQrhjRErp+cCmcpn2qqjuPp0oNN9gaJp65A0o=p0DUQ@mail.gmail.com>
From: Fabio Estevam <festevam@gmail.com> Sent: Thursday, March 31, 2016 6:57 PM
> To: Fugang Duan <fugang.duan@nxp.com>
> Cc: Greg Ungerer <gerg@uclinux.org>; Troy Kisky
> <troy.kisky@boundarydevices.com>; netdev@vger.kernel.org
> Subject: Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages
>
> Hi Andy,
>
> On Wed, Mar 30, 2016 at 10:41 PM, Fugang Duan <fugang.duan@nxp.com>
> wrote:
> >
> > Fabio, we cannot do it like this that may cause confused for the quirk flag
> "FEC_QUIRK_HAS_RACC".
>
> We can treat FEC_QUIRK_HAS_RACC flag as "this is a non-Coldfire SoC".
>
FEC_QUIRK_HAS_RACC means the HW support "Receive Accelerator Function Configuration". It is really make somebody confused.
To save trouble, you treat FEC_QUIRK_HAS_RACC flag as "this is a non-Coldfire SoC", you must add comment on the flag define.
> >
> >
> > Hi, Greg,
> >
> > The header file fec.h define the FEC_FTRL as below, if ColdFire SoC has no this
> register, we may remove the define in here and define the register according
> to SOC type. For example, it is ColdFire Soc, define it as 0xFFF. Is it feasible ?
> >
>
> This is even worse IMHO. We should not write to a 'fake' register offset of 0xFFF.
We can do it like this:
#if defined(CONFIG_ARM)
writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
#endif
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Eric Dumazet @ 2016-04-01 1:39 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: davem, netdev, sasha.levin, daniel, alexei.starovoitov, mkubecek
In-Reply-To: <1459474618.3751123.565321858.30DF1858@webmail.messagingengine.com>
On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote:
> On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
> > Thanks.
> >
> > As you can see, release_sock() messes badly lockdep (once your other
> > patches are in )
> >
> > Once we properly fix release_sock() and/or __release_sock(), all these
> > false positives disappear.
>
> This was a loopback connection. I need to study release_sock and
> __release_sock more as I cannot currently see an issue with the lockdep
> handling.
Okay, please try :
diff --git a/net/core/sock.c b/net/core/sock.c
index b67b9aedb230..570dcd91d64e 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2429,10 +2429,6 @@ EXPORT_SYMBOL(lock_sock_nested);
void release_sock(struct sock *sk)
{
- /*
- * The sk_lock has mutex_unlock() semantics:
- */
- mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);
spin_lock_bh(&sk->sk_lock.slock);
if (sk->sk_backlog.tail)
@@ -2445,6 +2441,10 @@ void release_sock(struct sock *sk)
sk->sk_prot->release_cb(sk);
sock_release_ownership(sk);
+ /*
+ * The sk_lock has mutex_unlock() semantics:
+ */
+ mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);
if (waitqueue_active(&sk->sk_lock.wq))
wake_up(&sk->sk_lock.wq);
spin_unlock_bh(&sk->sk_lock.slock);
^ permalink raw reply related
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Alexei Starovoitov @ 2016-04-01 1:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, davem, netdev, sasha.levin, daniel,
mkubecek
In-Reply-To: <1459473592.6473.243.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Mar 31, 2016 at 06:19:52PM -0700, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 02:21 +0200, Hannes Frederic Sowa wrote:
>
> >
> > [ 31.064029] ===============================
> > [ 31.064030] [ INFO: suspicious RCU usage. ]
> > [ 31.064032] 4.5.0+ #13 Not tainted
> > [ 31.064033] -------------------------------
> > [ 31.064034] include/net/sock.h:1594 suspicious
> > rcu_dereference_check() usage!
> > [ 31.064035]
> > other info that might help us debug this:
> >
> > [ 31.064041]
> > rcu_scheduler_active = 1, debug_locks = 1
> > [ 31.064042] no locks held by ssh/817.
> > [ 31.064043]
> > stack backtrace:
> > [ 31.064045] CPU: 0 PID: 817 Comm: ssh Not tainted 4.5.0+ #13
> > [ 31.064046] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> > BIOS 1.8.2-20150714_191134- 04/01/2014
> > [ 31.064047] 0000000000000286 000000006730b46b ffff8800badf7bd0
> > ffffffff81442b33
> > [ 31.064050] ffff8800b8c78000 0000000000000001 ffff8800badf7c00
> > ffffffff8110ae75
> > [ 31.064052] ffff880035ea2f00 ffff8800b8e28000 0000000000000003
> > 00000000000004c4
> > [ 31.064054] Call Trace:
> > [ 31.064058] [<ffffffff81442b33>] dump_stack+0x85/0xc2
> > [ 31.064062] [<ffffffff8110ae75>] lockdep_rcu_suspicious+0xc5/0x100
> > [ 31.064064] [<ffffffff8173bf57>] __sk_dst_check+0x77/0xb0
> > [ 31.064066] [<ffffffff8182e502>] inet6_sk_rebuild_header+0x52/0x300
> > [ 31.064068] [<ffffffff813bb61e>] ? selinux_skb_peerlbl_sid+0x5e/0xa0
> > [ 31.064070] [<ffffffff813bb69e>] ?
> > selinux_inet_conn_established+0x3e/0x40
> > [ 31.064072] [<ffffffff817c2bad>] tcp_finish_connect+0x4d/0x270
> > [ 31.064074] [<ffffffff817c33f7>] tcp_rcv_state_process+0x627/0xe40
> > [ 31.064076] [<ffffffff81866584>] tcp_v6_do_rcv+0xd4/0x410
> > [ 31.064078] [<ffffffff8173bc65>] release_sock+0x85/0x1c0
> > [ 31.064079] [<ffffffff817e9983>] __inet_stream_connect+0x1c3/0x340
> > [ 31.064081] [<ffffffff8173b089>] ? lock_sock_nested+0x49/0xb0
> > [ 31.064083] [<ffffffff81100270>] ? abort_exclusive_wait+0xb0/0xb0
> > [ 31.064084] [<ffffffff817e9b38>] inet_stream_connect+0x38/0x50
> > [ 31.064086] [<ffffffff8173794f>] SYSC_connect+0xcf/0xf0
> > [ 31.064088] [<ffffffff8110d069>] ? trace_hardirqs_on_caller+0x129/0x1b0
> > [ 31.064090] [<ffffffff8100301b>] ? trace_hardirqs_on_thunk+0x1b/0x1d
> > [ 31.064091] [<ffffffff8173854e>] SyS_connect+0xe/0x10
> > [ 31.064094] [<ffffffff818a0e7c>] entry_SYSCALL_64_fastpath+0x1f/0xbd
> >
> > Bye,
> > Hannes
>
> Thanks.
>
> As you can see, release_sock() messes badly lockdep (once your other
> patches are in )
>
> Once we properly fix release_sock() and/or __release_sock(), all these
> false positives disappear.
+1. Nice catch.
Eric, what's your take on Hannes's patch 2 ?
Is it more accurate to ask lockdep to check for actual lock
or lockdep can rely on owned flag?
Potentially there could be races between setting the flag and
actual lock... but that code is contained, so unlikely.
Will we find the real issues with this 'stronger' check or
just spend a ton of time adapting to new model like your other
patch for release_sock and whatever may need to come next...
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Eric Dumazet @ 2016-04-01 1:45 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: davem, netdev, sasha.levin, daniel, alexei.starovoitov, mkubecek
In-Reply-To: <1459474756.6473.248.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, 2016-03-31 at 18:39 -0700, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote:
> > On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
> > > Thanks.
> > >
> > > As you can see, release_sock() messes badly lockdep (once your other
> > > patches are in )
> > >
> > > Once we properly fix release_sock() and/or __release_sock(), all these
> > > false positives disappear.
> >
> > This was a loopback connection. I need to study release_sock and
> > __release_sock more as I cannot currently see an issue with the lockdep
> > handling.
>
> Okay, please try :
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index b67b9aedb230..570dcd91d64e 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2429,10 +2429,6 @@ EXPORT_SYMBOL(lock_sock_nested);
>
> void release_sock(struct sock *sk)
> {
> - /*
> - * The sk_lock has mutex_unlock() semantics:
> - */
> - mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);
>
> spin_lock_bh(&sk->sk_lock.slock);
> if (sk->sk_backlog.tail)
> @@ -2445,6 +2441,10 @@ void release_sock(struct sock *sk)
> sk->sk_prot->release_cb(sk);
>
> sock_release_ownership(sk);
> + /*
> + * The sk_lock has mutex_unlock() semantics:
> + */
> + mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);
> if (waitqueue_active(&sk->sk_lock.wq))
> wake_up(&sk->sk_lock.wq);
> spin_unlock_bh(&sk->sk_lock.slock);
Also take a look at commit c3f9b01849ef3bc69024990092b9f42e20df7797
We might need to include the mutex_release() in sock_release_ownership()
Thanks !
^ permalink raw reply
* RE: [PATCH] fec: Do not access unexisting register in Coldfire
From: Fugang Duan @ 2016-04-01 1:39 UTC (permalink / raw)
To: Fabio Estevam, davem@davemloft.net
Cc: troy.kisky@boundarydevices.com, gerg@uclinux.org,
netdev@vger.kernel.org, Fabio Estevam
In-Reply-To: <1459436717-12809-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com> Sent: Thursday, March 31, 2016 11:05 PM
> To: davem@davemloft.net
> Cc: Fugang Duan <fugang.duan@nxp.com>; troy.kisky@boundarydevices.com;
> gerg@uclinux.org; netdev@vger.kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>
> Subject: [PATCH] fec: Do not access unexisting register in Coldfire
>
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Commit 55cd48c821de ("net: fec: stop the "rcv is not +last, " error
> messages") introduces a write to a register that does not exist in Coldfire.
>
> Move the FEC_FTRL register access inside the FEC_QUIRK_HAS_RACC 'if' block,
> so that we guarantee it will not be used on Coldfire CPUs.
>
> Reported-by: Greg Ungerer <gerg@uclinux.org>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 37c0815..08243c2 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -943,8 +943,8 @@ fec_restart(struct net_device *ndev)
> else
> val &= ~FEC_RACC_OPTIONS;
> writel(val, fep->hwp + FEC_RACC);
> + writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
> }
> - writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
> #endif
>
> /*
> --
> 1.9.1
If you stick to do it like this, you must add comments on the quirk flag FEC_QUIRK_HAS_RACC.
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Hannes Frederic Sowa @ 2016-04-01 1:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, netdev, sasha.levin, daniel, alexei.starovoitov, mkubecek
In-Reply-To: <1459474756.6473.248.camel@edumazet-glaptop3.roam.corp.google.com>
On 01.04.2016 03:39, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote:
>> On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
>>> Thanks.
>>>
>>> As you can see, release_sock() messes badly lockdep (once your other
>>> patches are in )
>>>
>>> Once we properly fix release_sock() and/or __release_sock(), all these
>>> false positives disappear.
>>
>> This was a loopback connection. I need to study release_sock and
>> __release_sock more as I cannot currently see an issue with the lockdep
>> handling.
>
> Okay, please try :
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index b67b9aedb230..570dcd91d64e 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2429,10 +2429,6 @@ EXPORT_SYMBOL(lock_sock_nested);
>
> void release_sock(struct sock *sk)
> {
> - /*
> - * The sk_lock has mutex_unlock() semantics:
> - */
> - mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);
>
> spin_lock_bh(&sk->sk_lock.slock);
> if (sk->sk_backlog.tail)
> @@ -2445,6 +2441,10 @@ void release_sock(struct sock *sk)
> sk->sk_prot->release_cb(sk);
>
> sock_release_ownership(sk);
> + /*
> + * The sk_lock has mutex_unlock() semantics:
> + */
> + mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);
> if (waitqueue_active(&sk->sk_lock.wq))
> wake_up(&sk->sk_lock.wq);
> spin_unlock_bh(&sk->sk_lock.slock);
Looks much better with your patch already. I slowly begin to understand,
this is really tricky... :)
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Hannes Frederic Sowa @ 2016-04-01 2:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, netdev, sasha.levin, daniel, alexei.starovoitov, mkubecek
In-Reply-To: <1459475124.6473.250.camel@edumazet-glaptop3.roam.corp.google.com>
On 01.04.2016 03:45, Eric Dumazet wrote:
> On Thu, 2016-03-31 at 18:39 -0700, Eric Dumazet wrote:
>> On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote:
>>> On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
>>>> Thanks.
>>>>
>>>> As you can see, release_sock() messes badly lockdep (once your other
>>>> patches are in )
>>>>
>>>> Once we properly fix release_sock() and/or __release_sock(), all these
>>>> false positives disappear.
>>>
>>> This was a loopback connection. I need to study release_sock and
>>> __release_sock more as I cannot currently see an issue with the lockdep
>>> handling.
>>
>> Okay, please try :
>>
>> diff --git a/net/core/sock.c b/net/core/sock.c
>> index b67b9aedb230..570dcd91d64e 100644
>> --- a/net/core/sock.c
>> +++ b/net/core/sock.c
>> @@ -2429,10 +2429,6 @@ EXPORT_SYMBOL(lock_sock_nested);
>>
>> void release_sock(struct sock *sk)
>> {
>> - /*
>> - * The sk_lock has mutex_unlock() semantics:
>> - */
>> - mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);
>>
>> spin_lock_bh(&sk->sk_lock.slock);
>> if (sk->sk_backlog.tail)
>> @@ -2445,6 +2441,10 @@ void release_sock(struct sock *sk)
>> sk->sk_prot->release_cb(sk);
>>
>> sock_release_ownership(sk);
>> + /*
>> + * The sk_lock has mutex_unlock() semantics:
>> + */
>> + mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);
>> if (waitqueue_active(&sk->sk_lock.wq))
>> wake_up(&sk->sk_lock.wq);
>> spin_unlock_bh(&sk->sk_lock.slock);
>
> Also take a look at commit c3f9b01849ef3bc69024990092b9f42e20df7797
>
> We might need to include the mutex_release() in sock_release_ownership()
I thought so first, as well. But given the double check for the
spin_lock and the "mutex" we end up with the same result for the
lockdep_sock_is_held check.
Do you see other consequences?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu
From: Jason Wang @ 2016-04-01 2:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, mst, netdev, linux-kernel
In-Reply-To: <1459420341.6473.225.camel@edumazet-glaptop3.roam.corp.google.com>
On 03/31/2016 06:32 PM, Eric Dumazet wrote:
> On Thu, 2016-03-31 at 13:50 +0800, Jason Wang wrote:
>> We use a union for napi_id and send_cpu, this is ok for most of the
>> cases except when we want to support busy polling for tun which needs
>> napi_id to be stored and passed to socket during tun_net_xmit(). In
>> this case, napi_id was overridden with sender_cpu before tun_net_xmit()
>> was called if XPS was enabled. Fixing by not using union for napi_id
>> and sender_cpu.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> include/linux/skbuff.h | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 15d0df9..8aee891 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -743,11 +743,11 @@ struct sk_buff {
>> __u32 hash;
>> __be16 vlan_proto;
>> __u16 vlan_tci;
>> -#if defined(CONFIG_NET_RX_BUSY_POLL) || defined(CONFIG_XPS)
>> - union {
>> - unsigned int napi_id;
>> - unsigned int sender_cpu;
>> - };
>> +#if defined(CONFIG_NET_RX_BUSY_POLL)
>> + unsigned int napi_id;
>> +#endif
>> +#if defined(CONFIG_XPS)
>> + unsigned int sender_cpu;
>> #endif
>> union {
>> #ifdef CONFIG_NETWORK_SECMARK
> Hmmm...
>
> This is a serious problem.
>
> Making skb bigger (8 bytes because of alignment) was not considered
> valid for sender_cpu introduction. We worked quite hard to avoid this,
> if you take a look at git history :(
>
> Can you describe more precisely the problem and code path ?
>
The problem is we want to support busy polling for tun. This needs
napi_id to be passed to tun socket by sk_mark_napi_id() during
tun_net_xmit(). But before reaching this, XPS will set sender_cpu will
make us can't see correct napi_id.
^ permalink raw reply
* Re: [PULL REQUEST] Please pull rdma.git
From: David Miller @ 2016-04-01 2:18 UTC (permalink / raw)
To: leon-2ukJVAZIZ/Y
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
matanb-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20160331233828.GE2670-2ukJVAZIZ/Y@public.gmane.org>
From: Leon Romanovsky <leon-2ukJVAZIZ/Y@public.gmane.org>
Date: Fri, 1 Apr 2016 02:38:28 +0300
> On Wed, Mar 23, 2016 at 09:37:54AM -0400, Doug Ledford wrote:
>> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
>> > On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
>> >> So the *best* situation would be:
>> >>
>> >> - your two groups talk it over, and figure out what the common commits are
>> >>
>> >> - you put those common commits as a "base" branch in git
>> >>
>> >> - you ask the two upper-level maintainers to both pull that base branch
>> >>
>> >> - you then make sure that you send the later patches (whether as
>> >> emailed patches or as pull requests) based on top of that base branch.
>> >
>> > Hi David and Doug,
>> >
>> > Are you OK with the approach suggested by Linus?
>> > We are eager to know it, so we will adopt it as soon
>> > as possible in our development flow.
>> >
>> > The original thread [1].
>> >
>> > [1] http://thread.gmane.org/gmane.linux.drivers.rdma/34907
>> >
>> > Thanks.
>> >
>>
>> I'm fine with it. Since I happen to use topic branches to build my
>> for-next from anyway, I might need to be the one that Dave pulls from
>> versus the other way around.
>
> Resending to linux-netdev.
>
> David,
> Can you please express your opinion about Linus's suggestion to
> eliminate merge conflicts in Mellanox related products?
Sure, sounds fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: qdisc spin lock
From: David Miller @ 2016-04-01 2:19 UTC (permalink / raw)
To: make0818; +Cc: xiyou.wangcong, netdev
In-Reply-To: <CAAmHdhxagKnLP1_5ZW7HTsVBu0TSFYKCvNstAEWN-NHrdnvvVQ@mail.gmail.com>
From: Michael Ma <make0818@gmail.com>
Date: Thu, 31 Mar 2016 16:48:43 -0700
> I didn't really know that multiple qdiscs can be isolated using MQ so
...
Please stop top-posting.
^ permalink raw reply
* Re: Reboot Failed was occurred after v4.4-rc1 during IPv6 Ready Logo Conformance Test
From: Yuki Machida @ 2016-04-01 2:40 UTC (permalink / raw)
To: netdev
In-Reply-To: <56FCCD18.9050306@jp.fujitsu.com>
On 2016年03月31日 16:09, Yuki Machida wrote:
> Hi all,
>
> Reboot Failed was occurred at Linux Kernel after v4.4-rc1 during IPv6 Ready Logo Conformance Test.
> Not Fix a bug in v4.5-rc7 yet.
> I will conform that it fix a bug in v4.6-rc1.
I conform that it was not occurred in v4.6-rc1.
I will find a patch for this bug, and conform it was applied -stable kernel.
If it was not applied -stable kernel, I will report again.
> Currently, it is under investigation.
>
> IPv6 Ready Logo
> https://www.ipv6ready.org/
> TAHI Project
> http://www.tahi.org/
>
> I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510).
> It is using userland build with yocto project.
>
> Test Environment
> Test Specification : 4.0.6
> Tool Version : REL_3_3_2
> Test Program Version : V6LC_5_0_0
> Target Device : Intel D510MO (Atom D510)
>
> I conform that random testcases are failed.
> (e.g. No.5, No.130, No.131, No.134, No.167 and No.168)
>
> Regards,
> Yuki Machida
>
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu
From: Jason Wang @ 2016-04-01 2:46 UTC (permalink / raw)
To: David Miller, eric.dumazet; +Cc: mst, netdev, linux-kernel
In-Reply-To: <20160331.160115.1737831060132252055.davem@davemloft.net>
On 04/01/2016 04:01 AM, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 31 Mar 2016 03:32:21 -0700
>
>> On Thu, 2016-03-31 at 13:50 +0800, Jason Wang wrote:
>>> We use a union for napi_id and send_cpu, this is ok for most of the
>>> cases except when we want to support busy polling for tun which needs
>>> napi_id to be stored and passed to socket during tun_net_xmit(). In
>>> this case, napi_id was overridden with sender_cpu before tun_net_xmit()
>>> was called if XPS was enabled. Fixing by not using union for napi_id
>>> and sender_cpu.
>>>
>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>> ---
>>> include/linux/skbuff.h | 10 +++++-----
>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>> index 15d0df9..8aee891 100644
>>> --- a/include/linux/skbuff.h
>>> +++ b/include/linux/skbuff.h
>>> @@ -743,11 +743,11 @@ struct sk_buff {
>>> __u32 hash;
>>> __be16 vlan_proto;
>>> __u16 vlan_tci;
>>> -#if defined(CONFIG_NET_RX_BUSY_POLL) || defined(CONFIG_XPS)
>>> - union {
>>> - unsigned int napi_id;
>>> - unsigned int sender_cpu;
>>> - };
>>> +#if defined(CONFIG_NET_RX_BUSY_POLL)
>>> + unsigned int napi_id;
>>> +#endif
>>> +#if defined(CONFIG_XPS)
>>> + unsigned int sender_cpu;
>>> #endif
>>> union {
>>> #ifdef CONFIG_NETWORK_SECMARK
>> Hmmm...
>>
>> This is a serious problem.
>>
>> Making skb bigger (8 bytes because of alignment) was not considered
>> valid for sender_cpu introduction. We worked quite hard to avoid this,
>> if you take a look at git history :(
>>
>> Can you describe more precisely the problem and code path ?
> From what I can see they are doing busy poll loops in the TX code paths,
> as well as the RX code paths, of vhost.
>
> Doing this in the TX side makes little sense to me. The busy poll
> implementations in the drivers only process their RX queues when
> ->ndo_busy_poll() is invoked. So I wonder what this is accomplishing
> for the vhost TX case?
In vhost TX case, it's possible that new packets were arrived at rx
queue during tx polling. Consider tx and rx were processed in one
thread, poll rx looks feasible to me.
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu
From: Eric Dumazet @ 2016-04-01 2:55 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, mst, netdev, linux-kernel
In-Reply-To: <56FDD94E.8090908@redhat.com>
On Fri, 2016-04-01 at 10:13 +0800, Jason Wang wrote:
>
> The problem is we want to support busy polling for tun. This needs
> napi_id to be passed to tun socket by sk_mark_napi_id() during
> tun_net_xmit(). But before reaching this, XPS will set sender_cpu will
> make us can't see correct napi_id.
>
Looks like napi_id should have precedence then ?
Only forwarding should allow the field to be cleared to allow XPS to do
its job.
Maybe skb_sender_cpu_clear() was removed too early (commit
64d4e3431e686dc37ce388ba531c4c4e866fb141)
Look, it is 8pm here, I am pretty sure a solution can be found,
but I am also need to take a break, I started at 3am today...
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Eric Dumazet @ 2016-04-01 3:03 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Hannes Frederic Sowa, davem, netdev, sasha.levin, daniel,
mkubecek
In-Reply-To: <20160401014516.GA11017@ast-mbp.thefacebook.com>
On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote:
> Eric, what's your take on Hannes's patch 2 ?
> Is it more accurate to ask lockdep to check for actual lock
> or lockdep can rely on owned flag?
> Potentially there could be races between setting the flag and
> actual lock... but that code is contained, so unlikely.
> Will we find the real issues with this 'stronger' check or
> just spend a ton of time adapting to new model like your other
> patch for release_sock and whatever may need to come next...
More precise lockdep checks are certainly good, I only objected to 4/4
trying to work around another bug.
But why do we rush for 'net' tree ?
This looks net-next material to me.
Locking changes are often subtle, lets take the time to do them
properly.
^ permalink raw reply
* Re: [PULL REQUEST] Please pull rdma.git
From: Leon Romanovsky @ 2016-04-01 2:46 UTC (permalink / raw)
To: David Miller
Cc: dledford, torvalds, linux-rdma, netdev, matanb, ogerlitz, leonro
In-Reply-To: <20160331.221847.53272383417094737.davem@davemloft.net>
On Thu, Mar 31, 2016 at 10:18:47PM -0400, David Miller wrote:
> From: Leon Romanovsky <leon@leon.nu>
> Date: Fri, 1 Apr 2016 02:38:28 +0300
>
> > On Wed, Mar 23, 2016 at 09:37:54AM -0400, Doug Ledford wrote:
> >> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
> >> > On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
> >> >> So the *best* situation would be:
> >> >>
> >> >> - your two groups talk it over, and figure out what the common commits are
> >> >>
> >> >> - you put those common commits as a "base" branch in git
> >> >>
> >> >> - you ask the two upper-level maintainers to both pull that base branch
> >> >>
> >> >> - you then make sure that you send the later patches (whether as
> >> >> emailed patches or as pull requests) based on top of that base branch.
> >> >
> >> > Hi David and Doug,
> >> >
> >> > Are you OK with the approach suggested by Linus?
> >> > We are eager to know it, so we will adopt it as soon
> >> > as possible in our development flow.
> >> >
> >> > The original thread [1].
> >> >
> >> > [1] http://thread.gmane.org/gmane.linux.drivers.rdma/34907
> >> >
> >> > Thanks.
> >> >
> >>
> >> I'm fine with it. Since I happen to use topic branches to build my
> >> for-next from anyway, I might need to be the one that Dave pulls from
> >> versus the other way around.
> >
> > Resending to linux-netdev.
> >
> > David,
> > Can you please express your opinion about Linus's suggestion to
> > eliminate merge conflicts in Mellanox related products?
>
> Sure, sounds fine.
Thank you, I appreciate a lot Doug's and your openness and
willingness to help us eliminate the future merge obstacles.
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Hannes Frederic Sowa @ 2016-04-01 3:06 UTC (permalink / raw)
To: Eric Dumazet, Alexei Starovoitov
Cc: davem, netdev, sasha.levin, daniel, mkubecek
In-Reply-To: <1459479818.6473.265.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Apr 1, 2016, at 05:03, Eric Dumazet wrote:
> On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote:
>
> > Eric, what's your take on Hannes's patch 2 ?
> > Is it more accurate to ask lockdep to check for actual lock
> > or lockdep can rely on owned flag?
> > Potentially there could be races between setting the flag and
> > actual lock... but that code is contained, so unlikely.
> > Will we find the real issues with this 'stronger' check or
> > just spend a ton of time adapting to new model like your other
> > patch for release_sock and whatever may need to come next...
>
> More precise lockdep checks are certainly good, I only objected to 4/4
> trying to work around another bug.
>
> But why do we rush for 'net' tree ?
>
> This looks net-next material to me.
>
> Locking changes are often subtle, lets take the time to do them
> properly.
I certainly can see my mistake now trying to paper over the splats. Do
you object if I send the first patches to fix up the reported lockdep?
^ permalink raw reply
* [v7, 0/5] Fix eSDHC host version register bug
From: Yangbo Lu @ 2016-04-01 3:07 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Zhao Qiang, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
scott.wood-3arQi8VN3Tc, Rob Herring, Claudiu Manoil, Kumar Gala,
leoyang.li-3arQi8VN3Tc, xiaobo.xie-3arQi8VN3Tc
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first three patches are to add the GUTS driver.
The following two patches are to enable GUTS driver support to get SVR in eSDHC
driver and fix host version for T4240.
Yangbo Lu (5):
ARM64: dts: ls2080a: add device configuration node
soc: fsl: add GUTS driver for QorIQ platforms
dt: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 ++++
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++++++++++++++++++++
include/linux/fsl/guts.h | 98 ++++++++---------
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
15 files changed, 219 insertions(+), 58 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
^ permalink raw reply
* [v7, 1/5] ARM64: dts: ls2080a: add device configuration node
From: Yangbo Lu @ 2016-04-01 3:07 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Zhao Qiang, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
scott.wood-3arQi8VN3Tc, Rob Herring, Claudiu Manoil, Kumar Gala,
leoyang.li-3arQi8VN3Tc, xiaobo.xie-3arQi8VN3Tc
In-Reply-To: <1459480051-3701-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg@1e00000 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e00000 0x0 0x10000>;
+ little-endian;
+ };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v7, 2/5] soc: fsl: add GUTS driver for QorIQ platforms
From: Yangbo Lu @ 2016-04-01 3:07 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Zhao Qiang, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
scott.wood-3arQi8VN3Tc, Rob Herring, Claudiu Manoil, Kumar Gala,
leoyang.li-3arQi8VN3Tc, xiaobo.xie-3arQi8VN3Tc
In-Reply-To: <1459480051-3701-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
---
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 ++++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsl/guts.h | 98 +++++++++++++++++++-------------------
5 files changed, 179 insertions(+), 49 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 0000000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 0000000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/fsl/guts.h>
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+ svr = mfspr(SPRN_SVR);
+#endif
+ return svr;
+ }
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ /* For P Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", },
+ {}
+};
+
+int fsl_guts_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ mutex_lock(&guts_lock);
+ /* Initialize guts only once */
+ if (guts) {
+ ret = guts->regs ? 0 : -ENOMEM;
+ goto out;
+ }
+
+ np = of_find_matching_node(NULL, guts_of_match);
+ if (!np) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ guts = kzalloc(sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ guts->little_endian = of_property_read_bool(np, "little-endian");
+
+ guts->regs = of_iomap(np, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ of_node_put(np);
+ ret = 0;
+out:
+ mutex_unlock(&guts_lock);
+ return ret;
+}
+EXPORT_SYMBOL(fsl_guts_init);
diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
index 649e917..ac3103b 100644
--- a/include/linux/fsl/guts.h
+++ b/include/linux/fsl/guts.h
@@ -29,83 +29,85 @@
* #ifdefs.
*/
struct ccsr_guts {
- __be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
- __be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
- __be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
- __be32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
- __be32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
- __be32 pordevsr2; /* 0x.0014 - POR device status register 2 */
+ u32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
+ u32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
+ u32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
+ u32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
+ u32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
+ u32 pordevsr2; /* 0x.0014 - POR device status register 2 */
u8 res018[0x20 - 0x18];
- __be32 porcir; /* 0x.0020 - POR Configuration Information Register */
+ u32 porcir; /* 0x.0020 - POR Configuration Information Register */
u8 res024[0x30 - 0x24];
- __be32 gpiocr; /* 0x.0030 - GPIO Control Register */
+ u32 gpiocr; /* 0x.0030 - GPIO Control Register */
u8 res034[0x40 - 0x34];
- __be32 gpoutdr; /* 0x.0040 - General-Purpose Output Data Register */
+ u32 gpoutdr; /* 0x.0040 - General-Purpose Output Data Register */
u8 res044[0x50 - 0x44];
- __be32 gpindr; /* 0x.0050 - General-Purpose Input Data Register */
+ u32 gpindr; /* 0x.0050 - General-Purpose Input Data Register */
u8 res054[0x60 - 0x54];
- __be32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
- __be32 pmuxcr2; /* 0x.0064 - Alternate function signal multiplex control 2 */
- __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
+ u32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
+ u32 pmuxcr2; /* 0x.0064 - Alternate function signal multiplex control 2 */
+ u32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
u8 res06c[0x70 - 0x6c];
- __be32 devdisr; /* 0x.0070 - Device Disable Control */
+ u32 devdisr; /* 0x.0070 - Device Disable Control */
#define CCSR_GUTS_DEVDISR_TB1 0x00001000
#define CCSR_GUTS_DEVDISR_TB0 0x00004000
- __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
+ u32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
u8 res078[0x7c - 0x78];
- __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register */
- __be32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
- __be32 pmrccr; /* 0x.0084 - Power Management Reset Counter Configuration Register */
- __be32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter Configuration Register */
- __be32 pmcdr; /* 0x.008c - 4Power management clock disable register */
- __be32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
- __be32 rstrscr; /* 0x.0094 - Reset Request Status and Control Register */
- __be32 ectrstcr; /* 0x.0098 - Exception reset control register */
- __be32 autorstsr; /* 0x.009c - Automatic reset status register */
- __be32 pvr; /* 0x.00a0 - Processor Version Register */
- __be32 svr; /* 0x.00a4 - System Version Register */
+ u32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register */
+ u32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
+ u32 pmrccr; /* 0x.0084 - Power Management Reset Counter Configuration Register */
+ u32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter Configuration Register */
+ u32 pmcdr; /* 0x.008c - 4Power management clock disable register */
+ u32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
+ u32 rstrscr; /* 0x.0094 - Reset Request Status and Control Register */
+ u32 ectrstcr; /* 0x.0098 - Exception reset control register */
+ u32 autorstsr; /* 0x.009c - Automatic reset status register */
+ u32 pvr; /* 0x.00a0 - Processor Version Register */
+ u32 svr; /* 0x.00a4 - System Version Register */
u8 res0a8[0xb0 - 0xa8];
- __be32 rstcr; /* 0x.00b0 - Reset Control Register */
+ u32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x100 - 0xc4];
- __be32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
+ u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
There are 16 registers */
u8 res140[0x224 - 0x140];
- __be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
- __be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
+ u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
+ u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
- __be32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
+ u32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
u8 res608[0x800 - 0x608];
- __be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
+ u32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
- __be32 ircr; /* 0x.0900 - Infrared Control Register */
+ u32 ircr; /* 0x.0900 - Infrared Control Register */
u8 res904[0x908 - 0x904];
- __be32 dmacr; /* 0x.0908 - DMA Control Register */
+ u32 dmacr; /* 0x.0908 - DMA Control Register */
u8 res90c[0x914 - 0x90c];
- __be32 elbccr; /* 0x.0914 - eLBC Control Register */
+ u32 elbccr; /* 0x.0914 - eLBC Control Register */
u8 res918[0xb20 - 0x918];
- __be32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
- __be32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
- __be32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
+ u32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
+ u32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
+ u32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
u8 resb2c[0xe00 - 0xb2c];
- __be32 clkocr; /* 0x.0e00 - Clock Out Select Register */
+ u32 clkocr; /* 0x.0e00 - Clock Out Select Register */
u8 rese04[0xe10 - 0xe04];
- __be32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
+ u32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
u8 rese14[0xe20 - 0xe14];
- __be32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
- __be32 cpfor; /* 0x.0e24 - L2 charge pump fuse override register */
+ u32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
+ u32 cpfor; /* 0x.0e24 - L2 charge pump fuse override register */
u8 rese28[0xf04 - 0xe28];
- __be32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
- __be32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
+ u32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
+ u32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
u8 resf0c[0xf2c - 0xf0c];
- __be32 itcr; /* 0x.0f2c - Internal transaction control register */
+ u32 itcr; /* 0x.0f2c - Internal transaction control register */
u8 resf30[0xf40 - 0xf30];
- __be32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
- __be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
+ u32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
+ u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+u32 fsl_guts_get_svr(void);
+int fsl_guts_init(void);
/* Alternate function signal multiplex control */
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v7, 3/5] dt: move guts devicetree doc out of powerpc directory
From: Yangbo Lu @ 2016-04-01 3:07 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Zhao Qiang, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
scott.wood-3arQi8VN3Tc, Rob Herring, Claudiu Manoil, Kumar Gala,
leoyang.li-3arQi8VN3Tc, xiaobo.xie-3arQi8VN3Tc
In-Reply-To: <1459480051-3701-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
^ 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