Netdev List
 help / color / mirror / Atom feed
* Re: [net-bluetooth] question about potential null pointer dereference
From: Marcel Holtmann @ 2017-05-31  0:52 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
	open list:BLUETOOTH DRIVERS, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170530112328.Horde.PY1jf3InPf-6SU3kH9l7mtw-fU+oOHjIBR1LoJgMfuPDHBfZZeVsHd8q@public.gmane.org>

Hi Gustavo,

> While looking into Coverity ID 1357456 I ran into the following piece of code at net/bluetooth/smp.c:166
> 
> 166/* The following functions map to the LE SC SMP crypto functions
> 167 * AES-CMAC, f4, f5, f6, g2 and h6.
> 168 */
> 169
> 170static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,
> 171                    size_t len, u8 mac[16])
> 172{
> 173        uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
> 174        SHASH_DESC_ON_STACK(desc, tfm);
> 175        int err;
> 176
> 177        if (len > CMAC_MSG_MAX)
> 178                return -EFBIG;
> 179
> 180        if (!tfm) {
> 181                BT_ERR("tfm %p", tfm);
> 182                return -EINVAL;
> 183        }
> 184
> 185        desc->tfm = tfm;
> 186        desc->flags = 0;
> 187
> 188        /* Swap key and message from LSB to MSB */
> 189        swap_buf(k, tmp, 16);
> 190        swap_buf(m, msg_msb, len);
> 191
> 192        SMP_DBG("msg (len %zu) %*phN", len, (int) len, m);
> 193        SMP_DBG("key %16phN", k);
> 194
> 195        err = crypto_shash_setkey(tfm, tmp, 16);
> 196        if (err) {
> 197                BT_ERR("cipher setkey failed: %d", err);
> 198                return err;
> 199        }
> 200
> 201        err = crypto_shash_digest(desc, msg_msb, len, mac_msb);
> 202        shash_desc_zero(desc);
> 203        if (err) {
> 204                BT_ERR("Hash computation error %d", err);
> 205                return err;
> 206        }
> 207
> 208        swap_buf(mac_msb, mac, 16);
> 209
> 210        SMP_DBG("mac %16phN", mac);
> 211
> 212        return 0;
> 213}
> 
> The issue here is that line 180 implies that pointer tfm might be NULL. If this is the case, there is a potential NULL pointer dereference at line 174 once pointer tfm is indirectly dereferenced inside macro SHASH_DESC_ON_STACK().
> 
> My question is if there is any chance that pointer tfm maybe be NULL when calling macro SHASH_DESC_ON_STACK()?

I think the part you are after is this:

        smp->tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);                   
        if (IS_ERR(smp->tfm_cmac)) {                                             
                BT_ERR("Unable to create CMAC crypto context");                  
                crypto_free_cipher(smp->tfm_aes);                                
                kzfree(smp);                                                     
                return NULL;                                                     
        }         

So the tfm_cmac is part of the smp structure. However if there is no cipher, we destroy the smp structure and essentially run without SMP support. So it can not really be called anyway.

Maybe commenting this might be a good idea.

Regards

Marcel

^ permalink raw reply

* Re: [PATCH V2 2/3] net-next: dsa: add multi cpu port support
From: Andrew Lunn @ 2017-05-31  0:52 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: John Crispin, Vivien Didelot, David S . Miller, Sean Wang, jiri,
	idosch, netdev, linux-kernel
In-Reply-To: <881bf3fe-1ffb-b9fd-c844-da265f71370d@gmail.com>

On Tue, May 30, 2017 at 05:16:27PM -0700, Florian Fainelli wrote:
> On 05/30/2017 05:06 PM, Andrew Lunn wrote:
> >> - past the initial setup, if we start creating bridge devices and so on,
> >> we have no way to tell: group Ports 0-3 together and send traffic to CPU
> >> port 0, then let Port 5 alone and send traffic to CPU port 1, that's a
> >> DSA-only problem though, because we still have the CPU port(s) as
> >> independent network interfaces.
> > 
> > What is the problem here? Frames come out the master interface, get
> > untagged and passed to the slave interface and go upto the bridge. It
> > should all just work. Same in the reverse direction.
> 
> The problem is really that is you have multiple CPU ports, how do you
> define which one gets all the traffic by default? Ascending order of
> port number? Descending order?

I would probably default to round robin when allocating user ports to
CPU ports. That probably gives you the best default.

> I actually tend to think that most use cases our there are in the order
> of dedicating one CPU port to one corresponding switch port (user
> facing, or internal) in order to provided guaranteed bandwidth for that
> port.

Which is generally a waste of bandwidth. Best case, i get 40Mbps
Internet access. Meaning 960Mbps of a dedicated cpu port would be
wasted.

>  But as an user, I want to choose how the grouping is going to
> work, and right now, I cannot, unless this is hardcoded in Device Tree,
> which sounds both wrong and inadequate.

So how about round-robin default, and then devlink to move a user port
to a specific cpu port?

We also need to watch out for asymmetry. I think newer marvell chips
don't support egress to multiple CPU ports. Ingress to the switch i
think is unlimited. The older chips are more flexible in this
respect. So we need some degree of flexibility here.
 
	Andrew

^ permalink raw reply

* Re: [PATCH iproute2 0/4] ip: Add vrf show commmand
From: Stephen Hemminger @ 2017-05-31  0:56 UTC (permalink / raw)
  To: David Ahern; +Cc: netdev
In-Reply-To: <20170527233450.58015-1-dsahern@gmail.com>

On Sat, 27 May 2017 17:34:46 -0600
David Ahern <dsahern@gmail.com> wrote:

> Refactor ip address to export its capability to save a list of nlmsg's
> for links and its link filter. Use both to add an 'ip vrf show' command
> to list all configured VRF with table id.
> 
> David Ahern (4):
>   ip address: Export ip_linkaddr_list
>   ip address: Move filter struct to ip_common.h
>   ip address: Change print_linkinfo_brief to take filter as an input
>   ip vrf: Add show command
> 
>  include/libnetlink.h |  10 ++++
>  ip/ip_common.h       |  27 ++++++++-
>  ip/ipaddress.c       | 144 +++++++++++++++++++++++-------------------------
>  ip/iplink.c          |   2 +-
>  ip/ipvrf.c           | 153 +++++++++++++++++++++++++++++++++++++++++++++++++--
>  man/man8/ip-vrf.8    |  11 ++++
>  6 files changed, 266 insertions(+), 81 deletions(-)
> 

Looks good, series applied to master.

^ permalink raw reply

* RE: [PATCH net-next] net: ndisc.c: reduce size of __ndisc_fill_addr_option()
From: YUAN Linyu @ 2017-05-31  1:00 UTC (permalink / raw)
  To: David Ahern, Joe Perches, David Miller, cugyly@163.com
  Cc: netdev@vger.kernel.org
In-Reply-To: <fe3573ad-90d1-6673-1e09-f6f1b47527bb@gmail.com>

Ok, I will send v2 later

> -----Original Message-----
> From: David Ahern [mailto:dsahern@gmail.com]
> Sent: Wednesday, May 31, 2017 8:40 AM
> To: YUAN Linyu; David Ahern; Joe Perches; David Miller; cugyly@163.com
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH net-next] net: ndisc.c: reduce size of
> __ndisc_fill_addr_option()
> 
> On 5/30/17 6:29 PM, YUAN Linyu wrote:
> >>> that function should be converted to skb_put_zero once it hits net-next.
> >> I will check it
> > I can't find skb_put_zero
> 
> I believe the decision was to put it in Johannes' tree and it will make
> its way to DaveM's tree. Give some time.

^ permalink raw reply

* Re: [i40e] regression on TCP stream and TCP maerts, kernel-4.12.0-0.rc2
From: Alexander Duyck @ 2017-05-31  1:27 UTC (permalink / raw)
  To: Adam Okuliar, Mitch Williams, intel-wired-lan
  Cc: Netdev, Adrian Tomasov, Jeff Kirsher, Otto Sabart, Jirka Hladky
In-Reply-To: <CAKgT0UcdJQWqr_zxxi36a6_3iMwBNow-YS723i7t6xsKvAqvCA@mail.gmail.com>

On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar <aokuliar@redhat.com> wrote:
>> Hello,
>>
>> we found regression on intel card(XL710) with i40e driver. Regression is
>> about ~45%
>> on TCP_STREAM and TCP_MAERTS test for IPv4 and IPv6. Regression was first
>> visible in kernel-4.12.0-0.rc1.
>>
>> More details about results you can see in uploaded images in bugzilla. [0]
>>
>>
>> [0] https://bugzilla.kernel.org/show_bug.cgi?id=195923
>>
>>
>> Best regards, / S pozdravom,
>>
>> Adrián Tomašov
>> Kernel Performance QE
>> atomasov@redhat.com
>
> I have added the i40e driver maintainer and the intel-wired-lan
> mailing list so that we can make are developers aware of the issue.
>
> Thanks.
>
> - Alex

Adam,

We are having some issues trying to reproduce what you reported.

Can you provide some additional data. Specifically we would be looking
for an "ethtool -i", and an "ethtool -S" for the port before and after
the test. If you can attach it to the bugzilla that would be
appreciated.

Thanks.

- Alex

^ permalink raw reply

* [PATCH] isdn: Fix a sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31  1:40 UTC (permalink / raw)
  To: isdn, davem, geliangtang, keescook; +Cc: netdev, linux-kernel, Jia-Ju Bai

The driver may sleep under a spin lock, the function call path is:
isdn_ppp_mp_receive (acquire the lock)
  isdn_ppp_mp_reassembly
    isdn_ppp_push_higher
      isdn_ppp_decompress
        isdn_ppp_ccp_reset_trans
          isdn_ppp_ccp_reset_alloc_state
            kzalloc(GFP_KERNEL) --> may sleep

To fixed it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".

Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
 drivers/isdn/i4l/isdn_ppp.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/isdn/i4l/isdn_ppp.c b/drivers/isdn/i4l/isdn_ppp.c
index d07dd519..8aa158a 100644
--- a/drivers/isdn/i4l/isdn_ppp.c
+++ b/drivers/isdn/i4l/isdn_ppp.c
@@ -2364,7 +2364,7 @@ static struct ippp_ccp_reset_state *isdn_ppp_ccp_reset_alloc_state(struct ippp_s
 		       id);
 		return NULL;
 	} else {
-		rs = kzalloc(sizeof(struct ippp_ccp_reset_state), GFP_KERNEL);
+		rs = kzalloc(sizeof(struct ippp_ccp_reset_state), GFP_ATOMIC);
 		if (!rs)
 			return NULL;
 		rs->state = CCPResetIdle;
-- 
1.7.9.5

^ permalink raw reply related

* Re: Deleting a dynamic mac entry..
From: Manohar Kumar @ 2017-05-31  1:50 UTC (permalink / raw)
  To: Toshiaki Makita; +Cc: netdev, bridge
In-Reply-To: <45967005-7501-6c96-eb95-f83c5f631277@lab.ntt.co.jp>

Please see inline..

On Fri, May 26, 2017 at 1:15 AM, Toshiaki Makita
<makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2017/05/26 14:08, Manohar Kumar wrote:
>> On Wed, May 24, 2017 at 6:11 PM, Toshiaki Makita
>> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>> On 2017/05/25 3:05, Manohar Kumar wrote:
>>>> Thanks, Toshiaki.
>>>>
>>>> What is the right way to set the default_pvid using the bridge command
>>>> ? I tried this, which fails..
>>>>
>>>> root@net-3:~# ip link set dev vxlan0 name untagged type vlan id 0
>>>> RTNETLINK answers: Operation not supported
>>>> root@net-3:~#
>>>>
>>>> All the interfaces in the bridge are untagged.
>>>
>>> # ip link set br0 down
>>> # echo 0 > /sys/class/net/br0/bridge/default_pvid
>>>
>>
>> I have the bridge inside a network namespace. There is no
>> /sys/class/net entry for the bridge interface inside the namespace.
>>
>> I see online references to this concept of 'tagged' sysfs directories
>> to support namespaces. But its not clear how to access the sysfs
>> entries for a particular namespace.
>
> Did you remount /sys after entering netns?

No, that was the problem. Mounting /sys did the trick. Appreciate your help.

Trying to understanding this better. How is the sysfs tree maintained
per network namespace ? I assume only the /sys/class/net is per
network namespace and the rest of the /sys is shared with the host
namespace ? Also, how does mounting /sys in the network namespace make
the new /sys/class/net tree visible ?

thanks,
Manohar.


> If not, remount /sys or use "ip netns" which automatically do it.
>
>> Is there any other way to set the default_pvid for the bridge
>> interface inside namespace ?
>
> No, as of 3.19.
>
>
> Toshiaki Makita
>

^ permalink raw reply

* [PATCH] i40e: Fix a sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31  2:12 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: intel-wired-lan, netdev, linux-kernel, Jia-Ju Bai

The driver may sleep under a spin lock, and the function call path is:
i40e_ndo_set_vf_port_vlan (acquire the lock by spin_lock_bh)
  i40e_vsi_remove_pvid
    i40e_vlan_stripping_disable
      i40e_aq_update_vsi_params
        i40e_asq_send_command
          mutex_lock --> may sleep

To fixed it, the spin lock is released before "i40e_vsi_remove_pvid", and 
the lock is acquired again after this function.

Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 95c23fb..0fb38ca 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -3017,10 +3017,12 @@ int i40e_ndo_set_vf_port_vlan(struct net_device *netdev, int vf_id,
 					   VLAN_VID_MASK));
 	}
 
+	spin_unlock_bh(&vsi->mac_filter_hash_lock);
 	if (vlan_id || qos)
 		ret = i40e_vsi_add_pvid(vsi, vlanprio);
 	else
 		i40e_vsi_remove_pvid(vsi);
+	spin_lock_bh(&vsi->mac_filter_hash_lock);
 
 	if (vlan_id) {
 		dev_info(&pf->pdev->dev, "Setting VLAN %d, QOS 0x%x on VF %d\n",
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH] enic: Fix a sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31  2:34 UTC (permalink / raw)
  To: benve, _govind, neepatel; +Cc: netdev, linux-kernel, Jia-Ju Bai

The driver may sleep under a spin lock in some function call paths.
The 1st function call path is:
enic_reset (acquire the lock by spin_lock)
  enic_stop
    enic_synchronize_irqs
      synchronize_irq --> may sleep
The 2nd function call path is:
enic_reset (acquire the lock by spin_lock)
  enic_dev_soft_reset
    enic_dev_wait
      schedule_timeout_uninterruptible --> may sleep
The 3rd function call path is:
enic_reset (acquire the lock by spin_lock)
  enic_open
    enic_request_intr
      enic_set_rx_cpu_rmap
        enic_free_rx_cpu_rmap
          free_irq_cpu_rmap --> may sleep

To fix it, the "spin_lock" and "spin_unlock" are removed in enic_reset.

Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
 drivers/net/ethernet/cisco/enic/enic_main.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 4b87bee..2a9bef8 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2310,7 +2310,6 @@ static void enic_reset(struct work_struct *work)
 
 	rtnl_lock();
 
-	spin_lock(&enic->enic_api_lock);
 	enic_stop(enic->netdev);
 	enic_dev_soft_reset(enic);
 	enic_reset_addr_lists(enic);
@@ -2318,7 +2317,6 @@ static void enic_reset(struct work_struct *work)
 	enic_set_rss_nic_cfg(enic);
 	enic_dev_set_ig_vlan_rewrite_mode(enic);
 	enic_open(enic->netdev);
-	spin_unlock(&enic->enic_api_lock);
 	call_netdevice_notifiers(NETDEV_REBOOT, enic->netdev);
 
 	rtnl_unlock();
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH] enic: Fix another sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31  2:43 UTC (permalink / raw)
  To: benve, _govind, neepatel; +Cc: netdev, linux-kernel, Jia-Ju Bai

The driver may sleep under a spin lock in some function call paths.
The 1st function call path is:
enic_tx_hang_reset (acquire the lock by spin_lock)
  enic_stop
    enic_synchronize_irqs
      synchronize_irq --> may sleep
The 2nd function call path is:
enic_tx_hang_reset (acquire the lock by spin_lock)
  enic_dev_wait
    schedule_timeout_uninterruptible --> may sleep
The 3rd function call path is:
enic_tx_hang_reset (acquire the lock by spin_lock)
  enic_open
    enic_request_intr
      enic_set_rx_cpu_rmap
        enic_free_rx_cpu_rmap
          free_irq_cpu_rmap --> may sleep

To fix it, the "spin_lock" and "spin_unlock" are removed 
in enic_tx_hang_reset.

Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
 drivers/net/ethernet/cisco/enic/enic_main.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 4b87bee..d6523e2 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2330,7 +2330,6 @@ static void enic_tx_hang_reset(struct work_struct *work)
 
 	rtnl_lock();
 
-	spin_lock(&enic->enic_api_lock);
 	enic_dev_hang_notify(enic);
 	enic_stop(enic->netdev);
 	enic_dev_hang_reset(enic);
@@ -2339,7 +2338,6 @@ static void enic_tx_hang_reset(struct work_struct *work)
 	enic_set_rss_nic_cfg(enic);
 	enic_dev_set_ig_vlan_rewrite_mode(enic);
 	enic_open(enic->netdev);
-	spin_unlock(&enic->enic_api_lock);
 	call_netdevice_notifiers(NETDEV_REBOOT, enic->netdev);
 
 	rtnl_unlock();
-- 
1.7.9.5

^ permalink raw reply related

* Re: [PATCH net-next] bnxt_en: Fix xmit_more with BQL.
From: David Miller @ 2017-05-31  2:38 UTC (permalink / raw)
  To: michael.chan; +Cc: netdev
In-Reply-To: <1496188980-13392-1-git-send-email-michael.chan@broadcom.com>

From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 30 May 2017 20:03:00 -0400

> We need to write the doorbell if BQL has stopped the queue and
> skb->xmit_more is set.  Otherwise it is possible for the tx queue to
> rot and cause tx timeout.
> 
> Fixes: 4d172f21cefe ("bnxt_en: Implement xmit_more.")
> Suggested-by: Yuval Mintz <yuval.mintz@cavium.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next 4/8] bpf: Add BPF_PROG_GET_FD_BY_ID
From: kbuild test robot @ 2017-05-31  3:21 UTC (permalink / raw)
  To: Martin KaFai Lau
  Cc: kbuild-all, netdev, Alexei Starovoitov, Daniel Borkmann,
	kernel-team
In-Reply-To: <f149f2b1d90960adbfac2ea6546d6f7014e49494.1496189155.git.kafai@fb.com>

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

Hi Martin,

[auto build test ERROR on net-next/master]

url:    https://github.com/0day-ci/linux/commits/Martin-KaFai-Lau/bpf-Introduce-bpf_prog-ID/20170531-110650
config: x86_64-randconfig-x015-201722 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/bug.h:81:0,
                    from include/linux/bug.h:4,
                    from include/linux/thread_info.h:11,
                    from arch/x86/include/asm/preempt.h:6,
                    from include/linux/preempt.h:80,
                    from include/linux/spinlock.h:50,
                    from include/linux/seqlock.h:35,
                    from include/linux/time.h:5,
                    from include/linux/ktime.h:24,
                    from include/linux/timer.h:5,
                    from include/linux/workqueue.h:8,
                    from include/linux/bpf.h:12,
                    from kernel/bpf/syscall.c:12:
   kernel/bpf/syscall.c: In function 'bpf_prog_inc_not_zero':
>> kernel/bpf/syscall.c:834:16: error: implicit declaration of function 'lockdep_is_held' [-Werror=implicit-function-declaration]
     WARN_ON_ONCE(!lockdep_is_held(&prog_idr_lock));
                   ^
   include/asm-generic/bug.h:65:25: note: in definition of macro 'WARN_ON_ONCE'
     int __ret_warn_on = !!(condition);   \
                            ^~~~~~~~~
   cc1: some warnings being treated as errors

vim +/lockdep_is_held +834 kernel/bpf/syscall.c

   828	EXPORT_SYMBOL_GPL(bpf_prog_inc);
   829	
   830	static struct bpf_prog *bpf_prog_inc_not_zero(struct bpf_prog *prog)
   831	{
   832		int refold;
   833	
 > 834		WARN_ON_ONCE(!lockdep_is_held(&prog_idr_lock));
   835		refold = __atomic_add_unless(&prog->aux->refcnt, 1, 0);
   836	
   837		if (refold >= BPF_MAX_REFCNT) {

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28833 bytes --]

^ permalink raw reply

* Re: [net-bluetooth] question about potential null pointer dereference
From: Gustavo A. R. Silva @ 2017-05-31  3:29 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
	open list:BLUETOOTH DRIVERS, netdev, linux-kernel
In-Reply-To: <62DD828F-D88E-4916-BD0B-347E433ACCE6@holtmann.org>

Hi Marcel,

Quoting Marcel Holtmann <marcel@holtmann.org>:

> Hi Gustavo,
>
>> While looking into Coverity ID 1357456 I ran into the following  
>> piece of code at net/bluetooth/smp.c:166
>>
>> 166/* The following functions map to the LE SC SMP crypto functions
>> 167 * AES-CMAC, f4, f5, f6, g2 and h6.
>> 168 */
>> 169
>> 170static int aes_cmac(struct crypto_shash *tfm, const u8 k[16],  
>> const u8 *m,
>> 171                    size_t len, u8 mac[16])
>> 172{
>> 173        uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
>> 174        SHASH_DESC_ON_STACK(desc, tfm);
>> 175        int err;
>> 176
>> 177        if (len > CMAC_MSG_MAX)
>> 178                return -EFBIG;
>> 179
>> 180        if (!tfm) {
>> 181                BT_ERR("tfm %p", tfm);
>> 182                return -EINVAL;
>> 183        }
>> 184
>> 185        desc->tfm = tfm;
>> 186        desc->flags = 0;
>> 187
>> 188        /* Swap key and message from LSB to MSB */
>> 189        swap_buf(k, tmp, 16);
>> 190        swap_buf(m, msg_msb, len);
>> 191
>> 192        SMP_DBG("msg (len %zu) %*phN", len, (int) len, m);
>> 193        SMP_DBG("key %16phN", k);
>> 194
>> 195        err = crypto_shash_setkey(tfm, tmp, 16);
>> 196        if (err) {
>> 197                BT_ERR("cipher setkey failed: %d", err);
>> 198                return err;
>> 199        }
>> 200
>> 201        err = crypto_shash_digest(desc, msg_msb, len, mac_msb);
>> 202        shash_desc_zero(desc);
>> 203        if (err) {
>> 204                BT_ERR("Hash computation error %d", err);
>> 205                return err;
>> 206        }
>> 207
>> 208        swap_buf(mac_msb, mac, 16);
>> 209
>> 210        SMP_DBG("mac %16phN", mac);
>> 211
>> 212        return 0;
>> 213}
>>
>> The issue here is that line 180 implies that pointer tfm might be  
>> NULL. If this is the case, there is a potential NULL pointer  
>> dereference at line 174 once pointer tfm is indirectly dereferenced  
>> inside macro SHASH_DESC_ON_STACK().
>>
>> My question is if there is any chance that pointer tfm maybe be  
>> NULL when calling macro SHASH_DESC_ON_STACK()?
>
> I think the part you are after is this:
>
>         smp->tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
>         if (IS_ERR(smp->tfm_cmac)) {
>                 BT_ERR("Unable to create CMAC crypto context");
>                 crypto_free_cipher(smp->tfm_aes);
>                 kzfree(smp);
>                 return NULL;
>         }
>

Yeah, this makes it all clear.

> So the tfm_cmac is part of the smp structure. However if there is no  
> cipher, we destroy the smp structure and essentially run without SMP  
> support. So it can not really be called anyway.
>

What I take from this is that as a general rule, I should first try to  
identify whether the code I'm debugging is reachable or not, depending  
on the specific structures and variables I'm interested in.

> Maybe commenting this might be a good idea.
>

Yep, it wouldn't hurt.

In the meantime I will triage and document this as a false positive.

Thank you very much for the clarification, Marcel,
I really appreciate it.
--
Gustavo A. R. Silva

^ permalink raw reply

* Re: [net-bluetooth] question about potential null pointer dereference
From: Gustavo A. R. Silva @ 2017-05-31  3:36 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
	open list:BLUETOOTH DRIVERS, netdev, linux-kernel
In-Reply-To: <20170530222953.Horde.lmsiZcFwJeJ7pN4QQZ_Fyk7@gator4166.hostgator.com>

Hi Marcel,

Quoting "Gustavo A. R. Silva" <garsilva@embeddedor.com>:

> Hi Marcel,
>
> Quoting Marcel Holtmann <marcel@holtmann.org>:
>
>> Hi Gustavo,
>>
>>> While looking into Coverity ID 1357456 I ran into the following  
>>> piece of code at net/bluetooth/smp.c:166
>>>
>>> 166/* The following functions map to the LE SC SMP crypto functions
>>> 167 * AES-CMAC, f4, f5, f6, g2 and h6.
>>> 168 */
>>> 169
>>> 170static int aes_cmac(struct crypto_shash *tfm, const u8 k[16],  
>>> const u8 *m,
>>> 171                    size_t len, u8 mac[16])
>>> 172{
>>> 173        uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
>>> 174        SHASH_DESC_ON_STACK(desc, tfm);
>>> 175        int err;
>>> 176
>>> 177        if (len > CMAC_MSG_MAX)
>>> 178                return -EFBIG;
>>> 179
>>> 180        if (!tfm) {
>>> 181                BT_ERR("tfm %p", tfm);
>>> 182                return -EINVAL;
>>> 183        }
>>> 184

BTW, what do you think about removing the IF block above?

>>> 185        desc->tfm = tfm;
>>> 186        desc->flags = 0;
>>> 187
>>> 188        /* Swap key and message from LSB to MSB */
>>> 189        swap_buf(k, tmp, 16);
>>> 190        swap_buf(m, msg_msb, len);
>>> 191
>>> 192        SMP_DBG("msg (len %zu) %*phN", len, (int) len, m);
>>> 193        SMP_DBG("key %16phN", k);
>>> 194
>>> 195        err = crypto_shash_setkey(tfm, tmp, 16);
>>> 196        if (err) {
>>> 197                BT_ERR("cipher setkey failed: %d", err);
>>> 198                return err;
>>> 199        }
>>> 200
>>> 201        err = crypto_shash_digest(desc, msg_msb, len, mac_msb);
>>> 202        shash_desc_zero(desc);
>>> 203        if (err) {
>>> 204                BT_ERR("Hash computation error %d", err);
>>> 205                return err;
>>> 206        }
>>> 207
>>> 208        swap_buf(mac_msb, mac, 16);
>>> 209
>>> 210        SMP_DBG("mac %16phN", mac);
>>> 211
>>> 212        return 0;
>>> 213}
>>>
>>> The issue here is that line 180 implies that pointer tfm might be  
>>> NULL. If this is the case, there is a potential NULL pointer  
>>> dereference at line 174 once pointer tfm is indirectly  
>>> dereferenced inside macro SHASH_DESC_ON_STACK().
>>>
>>> My question is if there is any chance that pointer tfm maybe be  
>>> NULL when calling macro SHASH_DESC_ON_STACK()?
>>
>> I think the part you are after is this:
>>
>>        smp->tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
>>        if (IS_ERR(smp->tfm_cmac)) {
>>                BT_ERR("Unable to create CMAC crypto context");
>>                crypto_free_cipher(smp->tfm_aes);
>>                kzfree(smp);
>>                return NULL;
>>        }
>>
>
> Yeah, this makes it all clear.
>
>> So the tfm_cmac is part of the smp structure. However if there is  
>> no cipher, we destroy the smp structure and essentially run without  
>> SMP support. So it can not really be called anyway.
>>
>
> What I take from this is that as a general rule, I should first try  
> to identify whether the code I'm debugging is reachable or not,  
> depending on the specific structures and variables I'm interested in.
>
>> Maybe commenting this might be a good idea.
>>
>
> Yep, it wouldn't hurt.
>
> In the meantime I will triage and document this as a false positive.
>
> Thank you very much for the clarification, Marcel,
> I really appreciate it.
> --
> Gustavo A. R. Silva

Thanks
--
Gustavo A. R. Silva

^ permalink raw reply

* Re: [PATCH 1/2] ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties
From: Fabio Estevam @ 2017-05-31  4:08 UTC (permalink / raw)
  To: Leonard Crestez
  Cc: Shawn Guo, Florian Fainelli, Andrew Lunn, Andy Duan,
	netdev@vger.kernel.org, Johan Hovold, linux-kernel,
	Alexandre Belloni, Philipp Zabel, Fabio Estevam,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <d31aab90fbdecaf4c5f240becb2d0b0efb23f5c3.1496164448.git.leonard.crestez@nxp.com>

On Tue, May 30, 2017 at 2:34 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> Right now mach-imx6ul registers a fixup for the ksz8081 phy. The same
> register values can be set through the micrel phy driver by using dts
> properties.
>
> This seems preferable and allows cleanly fixing suspend/resume.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>

^ permalink raw reply

* Re: [PATCH net-next 0/8] Introduce bpf ID
From: Martin KaFai Lau @ 2017-05-31  4:30 UTC (permalink / raw)
  To: David Ahern; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <19cd3d0a-12eb-b8ca-a054-62d86ba2a509@gmail.com>

On Tue, May 30, 2017 at 06:35:37PM -0600, David Ahern wrote:
> On 5/30/17 6:08 PM, Martin KaFai Lau wrote:
> > This patch series:
> > 1) Introduce ID for both bpf_prog and bpf_map.
> > 2) Add bpf commands to iterate the prog IDs and map
> >    IDs of the system.
> > 3) Add bpf commands to get a prog/map fd from an ID
> > 4) Add bpf command to get prog/map info from a fd.
> >    The prog/map info is a jump start in this patchset
> >    and it is not meant to be a complete list.  They can
> >    be extended in the future patches.
>
> Interesting. This really simplifies the bpf retrieval I have been
> working on:
>     https://github.com/dsahern/linux/commits/bpf/retrieve-bpf-wip
>
> Having the net device, filter, route, socket, cgroup, etc return the ids
> for attached programs solves the problem of getting a reference to all
> of the places BPF programs can be placed.
Right, it is the idea.

I am also baking some follow-up patches for returning xdp-prog's id
through netlink.

>
> This patch set turns an id into a fd, and my patches allow the fd to be
> used to get the bpf code.

^ permalink raw reply

* [PATCH net-next] powerpc: use asm-generic/socket.h as much as possible
From: Stephen Rothwell @ 2017-05-31  5:43 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Michael Ellerman, Benjamin Herrenschmidt, PowerPC, Arnd Bergmann

asm-generic/socket.h already has an exception for the differences that
powerpc needs, so just include it after defining the differences.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/include/uapi/asm/socket.h | 92 +---------------------------------
 1 file changed, 1 insertion(+), 91 deletions(-)

Build tested using powerpc allyesconfig, pseries_le_defconfig, 32 bit
and 64 bit allnoconfig and ppc44x_defconfig builds.

Dave, this is on top of the net-next tree and I am sending it to you
since it would produce a conflict if it was merged via the powerpc tree.

diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index bc4ca72faf99..3c590c7c42c0 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -8,28 +8,6 @@
  * 2 of the License, or (at your option) any later version.
  */
 
-#include <asm/sockios.h>
-
-/* For setsockopt(2) */
-#define SOL_SOCKET	1
-
-#define SO_DEBUG	1
-#define SO_REUSEADDR	2
-#define SO_TYPE		3
-#define SO_ERROR	4
-#define SO_DONTROUTE	5
-#define SO_BROADCAST	6
-#define SO_SNDBUF	7
-#define SO_RCVBUF	8
-#define SO_SNDBUFFORCE	32
-#define SO_RCVBUFFORCE	33
-#define SO_KEEPALIVE	9
-#define SO_OOBINLINE	10
-#define SO_NO_CHECK	11
-#define SO_PRIORITY	12
-#define SO_LINGER	13
-#define SO_BSDCOMPAT	14
-#define SO_REUSEPORT	15
 #define SO_RCVLOWAT	16
 #define SO_SNDLOWAT	17
 #define SO_RCVTIMEO	18
@@ -37,74 +15,6 @@
 #define SO_PASSCRED	20
 #define SO_PEERCRED	21
 
-/* Security levels - as per NRL IPv6 - don't actually do anything */
-#define SO_SECURITY_AUTHENTICATION		22
-#define SO_SECURITY_ENCRYPTION_TRANSPORT	23
-#define SO_SECURITY_ENCRYPTION_NETWORK		24
-
-#define SO_BINDTODEVICE	25
-
-/* Socket filtering */
-#define SO_ATTACH_FILTER	26
-#define SO_DETACH_FILTER	27
-#define SO_GET_FILTER		SO_ATTACH_FILTER
-
-#define SO_PEERNAME		28
-#define SO_TIMESTAMP		29
-#define SCM_TIMESTAMP		SO_TIMESTAMP
-
-#define SO_ACCEPTCONN		30
-
-#define SO_PEERSEC		31
-#define SO_PASSSEC		34
-#define SO_TIMESTAMPNS		35
-#define SCM_TIMESTAMPNS		SO_TIMESTAMPNS
-
-#define SO_MARK			36
-
-#define SO_TIMESTAMPING		37
-#define SCM_TIMESTAMPING	SO_TIMESTAMPING
-
-#define SO_PROTOCOL		38
-#define SO_DOMAIN		39
-
-#define SO_RXQ_OVFL             40
-
-#define SO_WIFI_STATUS		41
-#define SCM_WIFI_STATUS		SO_WIFI_STATUS
-#define SO_PEEK_OFF		42
-
-/* Instruct lower device to use last 4-bytes of skb data as FCS */
-#define SO_NOFCS		43
-
-#define SO_LOCK_FILTER		44
-
-#define SO_SELECT_ERR_QUEUE	45
-
-#define SO_BUSY_POLL		46
-
-#define SO_MAX_PACING_RATE	47
-
-#define SO_BPF_EXTENSIONS	48
-
-#define SO_INCOMING_CPU		49
-
-#define SO_ATTACH_BPF		50
-#define SO_DETACH_BPF		SO_DETACH_FILTER
-
-#define SO_ATTACH_REUSEPORT_CBPF	51
-#define SO_ATTACH_REUSEPORT_EBPF	52
-
-#define SO_CNX_ADVICE		53
-
-#define SCM_TIMESTAMPING_OPT_STATS	54
-
-#define SO_MEMINFO		55
-
-#define SO_INCOMING_NAPI_ID	56
-
-#define SO_COOKIE		57
-
-#define SCM_TIMESTAMPING_PKTINFO	58
+#include <asm-generic/socket.h>
 
 #endif	/* _ASM_POWERPC_SOCKET_H */
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply related

* Re: [PULL] topic/e1000e-fix
From: Daniel Vetter @ 2017-05-31  6:10 UTC (permalink / raw)
  To: Dave Airlie
  Cc: netdev, intel-gfx@lists.freedesktop.org,
	Linux Kernel Mailing List, intel-wired-lan, dri-devel,
	David Miller, Jeff Kirsher
In-Reply-To: <CAKMK7uF-b1U7qipgEoYnAjDtrNdvKYT4KkoV2=krikkdGERkCw@mail.gmail.com>

On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie <airlied@gmail.com> wrote:
>> On 31 May 2017 at 08:10, David Miller <davem@davemloft.net> wrote:
>>> From: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Date: Tue, 30 May 2017 22:15:42 +0200
>>>
>>>> If the e1000e maintainer wants to coalesce or not return statements
>>>> this simple way, that's imo on him to change the color as needed.
>>>
>>> That's not how things work.
>>>
>>> If the maintainer wants you to style things a certain way, either you
>>> do it that way or your patch isn't accepted.
>
> Consider this pull a regression report, pls handle it.

And I guess I pile of more cc, to make this regression report
complete. I mean you got the backtrace, bisect and a proposed fix, and
the almost-whitespace change demanded is something gcc does in its
sleep. I'd understand a request to retest if it would be a real
functional change, but in this situation I have no idea why this
regression just can't be fixed already.

Not sure if it's really preferred if regression reports come
incomplete, without bugfix and bisect attached.
-Daniel

>> I'm not really sure why Chris just couldn't respin already.
>>
>> Though really I think Chris should have just asked for a revert of the
>> original patch that broke stuff, instead of trying to patch a driver
>> if he doesn't have time to get the patch right for the maintainer.
>
> Ok, can we pls revert 2800209994f8 ("e1000e: Refactor PM flows") then?
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* [PATCH net] mpls: fix clearing of dead nh_flags on link up
From: Roopa Prabhu @ 2017-05-31  6:50 UTC (permalink / raw)
  To: davem; +Cc: netdev, dsahern

From: Roopa Prabhu <roopa@cumulusnetworks.com>

recent fixes to use WRITE_ONCE for nh_flags on link up,
accidently ended up leaving the deadflags on a nh. This patch
fixes the WRITE_ONCE to use freshly evaluated nh_flags.

Fixes: 39eb8cd17588 ("net: mpls: rt_nhn_alive and nh_flags should be accessed using READ_ONCE")
Reported-by: Satish Ashok <sashok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
 net/mpls/af_mpls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 94b3317..b51582d 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -1483,7 +1483,7 @@ static void mpls_ifup(struct net_device *dev, unsigned int flags)
 				continue;
 			alive++;
 			nh_flags &= ~flags;
-			WRITE_ONCE(nh->nh_flags, flags);
+			WRITE_ONCE(nh->nh_flags, nh_flags);
 		} endfor_nexthops(rt);
 
 		WRITE_ONCE(rt->rt_nhn_alive, alive);
-- 
1.9.1

^ permalink raw reply related

* [PATCH] mISDN: Fix a sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31  7:08 UTC (permalink / raw)
  To: isdn, mingo, fweisbec, geliangtang, akpm, davem, yamada.masahiro
  Cc: netdev, linux-kernel, Jia-Ju Bai

The driver may sleep under a read spin lock, and the function call path is:
send_socklist (acquire the lock by read_lock)
  skb_copy(GFP_KERNEL) --> may sleep

To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".

Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
 drivers/isdn/mISDN/stack.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/isdn/mISDN/stack.c b/drivers/isdn/mISDN/stack.c
index 8b7faea..422dced 100644
--- a/drivers/isdn/mISDN/stack.c
+++ b/drivers/isdn/mISDN/stack.c
@@ -75,7 +75,7 @@
 		if (sk->sk_state != MISDN_BOUND)
 			continue;
 		if (!cskb)
-			cskb = skb_copy(skb, GFP_KERNEL);
+			cskb = skb_copy(skb, GFP_ATOMIC);
 		if (!cskb) {
 			printk(KERN_WARNING "%s no skb\n", __func__);
 			break;
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-05-31  7:18 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
	linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
	will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
	alexandre.torgue-qxv4g6HH51o
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe

Hello

This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
present on Allwinner H3/H5/A83T/A64 SoCs.

This driver is the continuation of the sun8i-emac driver.
During the development, it appeared that in fact the hardware was a modified
version of some dwmac.
So the driver is now written as a glue driver for stmmac.

It supports 10/100/1000 Mbit/s speed with half/full duplex.
It can use an internal PHY (MII 10/100) or an external PHY
via RGMII/RMII.

This patch series enable the driver only for the H3/A64/H5 SoC since A83T
doesn't have the necessary clocks present in mainline.

The driver have been tested on the following boards:
- H3 Orange PI PC, BananaPI-M2+
- A64 Pine64, BananaPi-M64
- A83T BananaPI-M3

The first two patchs are some mandatory changes for letting dwmac-sun8i be used.
The following three patchs add the driver and its documentation.
The remaining are DT patch enabling it.

Regards
Corentin Labbe

Changes since v5:
- Added DT patch for NanoPi neo
- Use the new adjust_link variables (speedxxx/speedmask)
- Made the timeout of readl_poll_timeout from 10 to 100ms
- Fix sun8i_unpower_phy that could be called twice
- Replace phy by phy-handle in doc/dwmac-sun8i.txt

Changes since v4:
- Re-ordered by alphabetical order some DT nodes
- Simplified power/unpower_phy functions by testing the use of internal_phy
- Added a patch for adding dwmac-sun8i to arm64 defconfig
- Fix a typo in sun50i-a64-system-controller (wrongly used sun8i)
- Reworked uc/mc filter address setting

Changes since v3:
- Renamed tx-delay/rx-delay to tx-delay-ps/rx-delay-ps
- fix syscon compatible example
- Changed parameter type for setup() function
- Dropped some DT patchs for boards which I could not test further

Changes since v2:
- corrected order of syscon compatible
- added compatible = "ethernet-phy-ieee802.3-c22 to PHY
- added set_mac function

Changes since v1:
- added TX/RX delay units
- splitted syscon documentation in its own patch
- regulator is now disabled after clk_prepare_enable(gmac->tx_clk) error
- Fixed a memory leak on mac_device_info
- Use now generic pin config for all DT stuff
- CONFIG_DWMAC_SUN8I is now set to y in defconfigs

Corentin Labbe (21):
  net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
  net-next: stmmac: add optional setup function
  dt-bindings: net-next: Add DT bindings documentation for Allwinner
    dwmac-sun8i
  dt-bindings: syscon: Add DT bindings documentation for Allwinner
    syscon
  net-next: stmmac: Add dwmac-sun8i
  arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
  arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
  arm: sun8i: orangepi-pc: Enable dwmac-sun8i
  arm: sun8i: orangepi-zero: Enable dwmac-sun8i
  arm: sun8i: orangepi-one: Enable dwmac-sun8i
  arm: sun8i: orangepi-2: Enable dwmac-sun8i
  arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
  arm: sun8i: nanopi-neo: Enable dwmac-sun8i
  arm64: allwinner: sun50i-a64: Add dt node for the syscon control
    module
  arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
  arm64: allwinner: pine64: Enable dwmac-sun8i
  arm64: allwinner: pine64-plus: Enable dwmac-sun8i
  arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
  arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
  arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
  arm64: defconfig: Enable dwmac-sun8i driver on defconfig

 .../devicetree/bindings/misc/allwinner,syscon.txt  |  19 +
 .../devicetree/bindings/net/dwmac-sun8i.txt        |  78 ++
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts  |   8 +
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts          |   7 +
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts          |   8 +
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts        |   8 +
 arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts    |   5 +
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts         |   8 +
 arch/arm/boot/dts/sunxi-h3-h5.dtsi                 |  40 +
 arch/arm/configs/multi_v7_defconfig                |   1 +
 arch/arm/configs/sunxi_defconfig                   |   1 +
 .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts |  15 +
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  17 +-
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  16 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      |  41 +
 arch/arm64/configs/defconfig                       |   1 +
 drivers/net/ethernet/stmicro/stmmac/Kconfig        |  11 +
 drivers/net/ethernet/stmicro/stmmac/Makefile       |   1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  | 990 +++++++++++++++++++++
 drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c    |   3 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  19 +-
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   9 +-
 include/linux/stmmac.h                             |   2 +
 23 files changed, 1303 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
 create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c

-- 
2.13.0

^ permalink raw reply

* [PATCH v6 01/21] net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
From: Corentin Labbe @ 2017-05-31  7:18 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
	linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
	will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
	alexandre.torgue-qxv4g6HH51o
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Thoses symbol will be needed for the dwmac-sun8i ethernet driver.
For letting it to be build as module, they need to be exported.

Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 38f94305aab5..67af0bdd7f10 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -248,6 +248,7 @@ void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
 	data = (addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) | addr[0];
 	writel(data, ioaddr + low);
 }
+EXPORT_SYMBOL_GPL(stmmac_set_mac_addr);
 
 /* Enable disable MAC RX/TX */
 void stmmac_set_mac(void __iomem *ioaddr, bool enable)
@@ -279,4 +280,4 @@ void stmmac_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
 	addr[4] = hi_addr & 0xff;
 	addr[5] = (hi_addr >> 8) & 0xff;
 }
-
+EXPORT_SYMBOL_GPL(stmmac_get_mac_addr);
-- 
2.13.0

^ permalink raw reply related

* [PATCH v6 02/21] net-next: stmmac: add optional setup function
From: Corentin Labbe @ 2017-05-31  7:18 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
	linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
	will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
	alexandre.torgue-qxv4g6HH51o
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Instead of adding more ifthen logic for adding a new mac_device_info
setup function, it is easier to add a function pointer to the function
needed.

Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
 include/linux/stmmac.h                            | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f158273eab9b..c80c9c3b67db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3933,7 +3933,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
 	struct mac_device_info *mac;
 
 	/* Identify the MAC HW device */
-	if (priv->plat->has_gmac) {
+	if (priv->plat->setup) {
+		mac = priv->plat->setup(priv);
+	} else if (priv->plat->has_gmac) {
 		priv->dev->priv_flags |= IFF_UNICAST_FLT;
 		mac = dwmac1000_setup(priv->ioaddr,
 				      priv->plat->multicast_filter_bins,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 3921cb9dfadb..8bb550bca96d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -177,6 +177,7 @@ struct plat_stmmacenet_data {
 	void (*fix_mac_speed)(void *priv, unsigned int speed);
 	int (*init)(struct platform_device *pdev, void *priv);
 	void (*exit)(struct platform_device *pdev, void *priv);
+	struct mac_device_info *(*setup)(void *priv);
 	void *bsp_priv;
 	struct clk *stmmac_clk;
 	struct clk *pclk;
-- 
2.13.0

^ permalink raw reply related

* [PATCH v6 03/21] dt-bindings: net-next: Add DT bindings documentation for Allwinner dwmac-sun8i
From: Corentin Labbe @ 2017-05-31  7:18 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
	linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
	will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
	alexandre.torgue-qxv4g6HH51o
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

This patch adds documentation for Device-Tree bindings for the
Allwinner dwmac-sun8i driver.

Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 .../devicetree/bindings/net/dwmac-sun8i.txt        | 78 ++++++++++++++++++++++
 1 file changed, 78 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
new file mode 100644
index 000000000000..08e708c73193
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -0,0 +1,78 @@
+* Allwinner sun8i GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+- compatible: should be one of the following string:
+		"allwinner,sun8i-a83t-emac"
+		"allwinner,sun8i-h3-emac"
+		"allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- interrupts: interrupt for the device
+- interrupt-names: should be "macirq"
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "stmmaceth"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "stmmaceth"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+- syscon: A phandle to the syscon of the SoC with one of the following
+ compatible string:
+  - allwinner,sun8i-h3-system-controller
+  - allwinner,sun50i-a64-system-controller
+  - allwinner,sun8i-a83t-system-controller
+
+Optional properties:
+- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
+- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
+Both delay properties need to be a multiple of 100. They control the delay for
+external PHY.
+
+Optional properties for "allwinner,sun8i-h3-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with "allwinner,sun8i-h3-emac":
+- clocks: a phandle to the reference clock for the EPHY
+- resets: a phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet@1c0b000 {
+	compatible = "allwinner,sun8i-h3-emac";
+	syscon = <&syscon>;
+	reg = <0x01c0b000 0x104>;
+	interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+	interrupt-names = "macirq";
+	resets = <&ccu RST_BUS_EMAC>;
+	reset-names = "stmmaceth";
+	clocks = <&ccu CLK_BUS_EMAC>;
+	clock-names = "stmmaceth";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	phy-handle = <&int_mii_phy>;
+	phy-mode = "mii";
+	allwinner,leds-active-low;
+	mdio: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		int_mii_phy: ethernet-phy@1 {
+			reg = <1>;
+			clocks = <&ccu CLK_BUS_EPHY>;
+			resets = <&ccu RST_BUS_EPHY>;
+		};
+	};
+};
-- 
2.13.0

^ permalink raw reply related

* [PATCH v6 04/21] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Corentin Labbe @ 2017-05-31  7:18 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
	linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
	will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
	alexandre.torgue-qxv4g6HH51o
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

This patch adds documentation for Device-Tree bindings for the
syscon present in allwinner devices.

Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 .../devicetree/bindings/misc/allwinner,syscon.txt     | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt

diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
new file mode 100644
index 000000000000..cb5769137c6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
@@ -0,0 +1,19 @@
+* Allwinner sun8i system controller
+
+This file describes the bindings for the system controller present in
+Allwinner SoC H3, A83T and A64.
+The principal function of this syscon is to control EMAC PHY choice and
+config.
+
+Required properties for the system controller:
+- reg: address and length of the register for the device.
+- compatible: should be "syscon" and one of the following string:
+		"allwinner,sun8i-h3-system-controller"
+		"allwinner,sun50i-a64-system-controller"
+		"allwinner,sun8i-a83t-system-controller"
+
+Example:
+syscon: syscon@1c00000 {
+	compatible = "allwinner,sun8i-h3-system-controller", "syscon";
+	reg = <0x01c00000 0x1000>;
+};
-- 
2.13.0

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox