Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 9月, 2016 7 次提交
  3. 29 9月, 2016 6 次提交
    • D
      Merge branch 'qcom-emac-acpi' · 31fbe81f
      由 David S. Miller 提交于 
      Timur Tabi says:

====================
Add basic ACPI support to the Qualcomm Technologies EMAC driver

This patch series adds support to the EMAC driver for extracting addresses,
interrupts, and some _DSDs (properties) from ACPI.  The first two patches
clean up the code, and the third patch adds ACPI-specific functionality.

The first patch fixes a bug with handling the platform_device for the
internal PHY.  This phy is treated as a separate device in both DT and
ACPI, but since the platform is not released automatically when the
driver unloads, managed functions like devm_ioremap_resource cannot be
used.

The second patch replaces of_get_mac_address with its platform-independent
equivalent device_get_mac_address.

The third patch parses the ACPI tables to obtain the platform_device for
the primary EMAC node ("QCOM8070") and the internal phy node ("QCOM8071").
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31fbe81f
    • T
      net: qcom/emac: initial ACPI support · 5f3d3807
      由 Timur Tabi 提交于 
      Add support for reading addresses, interrupts, and _DSD properties
from ACPI tables, just like with device tree.  The HID for the
EMAC device itself is QCOM8070.  The internal PHY is represented
by a child node with a HID of QCOM8071.

The EMAC also has some complex clock initialization requirements
that are not represented by this patch.  This will be addressed
in a future patch.
Signed-off-by: NTimur Tabi <timur@codeaurora.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f3d3807
    • T
      net: qcom/emac: use device_get_mac_address · 0de709ac
      由 Timur Tabi 提交于 
      Replace the DT-specific of_get_mac_address() function with
device_get_mac_address, which works on both DT and ACPI platforms.  This
change makes it easier to add ACPI support.
Signed-off-by: NTimur Tabi <timur@codeaurora.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0de709ac
    • T
      net: qcom/emac: do not use devm on internal phy pdev · 54e19bc7
      由 Timur Tabi 提交于 
      The platform_device returned by of_find_device_by_node() is not
automatically released when the driver unprobes.  Therefore,
managed calls like devm_ioremap_resource() should not be used.
Instead, we manually allocate the resources and then free them
on driver release.
Signed-off-by: NTimur Tabi <timur@codeaurora.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      54e19bc7
    • J
      bpf: allow access into map value arrays · 48461135
      由 Josef Bacik 提交于 
      Suppose you have a map array value that is something like this

struct foo {
	unsigned iter;
	int array[SOME_CONSTANT];
};

You can easily insert this into an array, but you cannot modify the contents of
foo->array[] after the fact.  This is because we have no way to verify we won't
go off the end of the array at verification time.  This patch provides a start
for this work.  We accomplish this by keeping track of a minimum and maximum
value a register could be while we're checking the code.  Then at the time we
try to do an access into a MAP_VALUE we verify that the maximum offset into that
region is a valid access into that memory region.  So in practice, code such as
this

unsigned index = 0;

if (foo->iter >= SOME_CONSTANT)
	foo->iter = index;
else
	index = foo->iter++;
foo->array[index] = bar;

would be allowed, as we can verify that index will always be between 0 and
SOME_CONSTANT-1.  If you wish to use signed values you'll have to have an extra
check to make sure the index isn't less than 0, or do something like index %=
SOME_CONSTANT.
Signed-off-by: NJosef Bacik <jbacik@fb.com>
Acked-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48461135
    • E
      net: do not export sk_stream_write_space · 7836667c
      由 Eric Dumazet 提交于 
      Since commit 900f65d3 ("tcp: move duplicate code from
tcp_v4_init_sock()/tcp_v6_init_sock()") we no longer need
to export sk_stream_write_space()

From: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7836667c
  5. 28 9月, 2016 18 次提交
  7. 27 9月, 2016 9 次提交
    • J
      bnx2x: free the mac filter group list before freeing the cmd · e96e0ede
      由 jbaron@akamai.com 提交于 
      The group list must be freed prior to freeing the command otherwise
we have a use-after-free.
Signed-off-by: NJason Baron <jbaron@akamai.com>
Cc: Yuval Mintz <Yuval.Mintz@qlogic.com>
Cc: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e96e0ede
    • D
      Merge branch 'mediatek-pdam-lro-fixes' · 44675a6d
      由 David S. Miller 提交于 
      Nelson Chang says:

====================
net: ethernet: mediatek: some bug fixes for PDAM and HW LRO

1) Add to stop PDMA while stopping the frame engine
2) Modify the register settings for LRO relinquishments
3) Jump out from the waiting loop while LRO relinquishments are done
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44675a6d
    • N
      net: ethernet: mediatek: bug fix to disable HW LRO · ca3ba106
      由 Nelson Chang 提交于 
      (1) Modify the register settings for LRO relinquishments
(2) Jump out from the waiting loop while LRO relinquishments are done
Signed-off-by: NNelson Chang <nelson.chang@mediatek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca3ba106
    • N
      net: ethernet: mediatek: add to stop PDMA while stopping the frame engine · 6bf563d5
      由 Nelson Chang 提交于 
      Stop PDMA while the frame engine is going to stop.
Signed-off-by: NNelson Chang <nelson.chang@mediatek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6bf563d5
    • D
      Merge branch 'bcmgenet-phydev-revert' · 3783c09e
      由 David S. Miller 提交于 
      Philippe Reynes says:

====================
net: bcmgenet: only use new api ethtool_{get|set}_link_ksettings

Some times ago, a serie of patches were committed :
- commit 62469c76 ("net: ethernet: bcmgenet: use phydev from struct net_device")
- commit 6b352ebc ("net: ethernet: broadcom: bcmgenet: use new api ethtool_{get|set}_link_ksettings")
The first patch add a regression on this driver, so it should be reverted.
As the second patch depend on the former, it should be reverted too.

The first patch is buggy because there is a "trick" in this driver.
The structure phydev is kept in the private data when the interface
go down, and used when the interface go up to enable the phy before
the function phy_connect is called.

I don't have this hardware, neither the datasheet. So I won't
update the driver to avoid this trick.

But the real goal of the first serie was to move to the new api
ethtool_{get|set}_link_ksettings. So I provide a new version of
the patch without the "cleaning" of driver to use the phydev
store in the net_device structure.

Changelog:
v3:
- use priv instead of dev (so all the code use the same phydev)
v2:
- use Florian Fainelli patches for the revert instead of Jaedon Shin
- simply use net: bcmgenet: for the prefix of the patch
====================
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3783c09e
    • P
      net: bcmgenet: use new api ethtool_{get|set}_link_ksettings · fa92bf04
      由 Philippe Reynes 提交于 
      The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
Signed-off-by: NPhilippe Reynes <tremyfr@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa92bf04
    • F
      Revert "net: ethernet: bcmgenet: use phydev from struct net_device" · 0299b6ac
      由 Florian Fainelli 提交于 
      This reverts commit 62469c76 ("net: ethernet: bcmgenet: use phydev
from struct net_device") because it causes GENETv1/2/3 adapters to
expose the following behavior after an ifconfig down/up sequence:

PING fainelli-linux (10.112.156.244): 56 data bytes
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.352 ms
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.472 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.496 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.517 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.536 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.557 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=752.448 ms (DUP!)

This was previously fixed by commit 5dbebbb4 ("net: bcmgenet:
Software reset EPHY after power on") but the commit we are reverting was
essentially making this previous commit void, here is why.

Without commit 62469c76 we would have the following scenario after
an ifconfig down then up sequence:

- bcmgenet_open() calls bcmgenet_power_up() to make sure the PHY is
  initialized *before* we get to initialize the UniMAC, this is
  critical to ensure the PHY is in a correct state, priv->phydev is
  valid, this code executes fine

- second time from bcmgenet_mii_probe(), through the normal
  phy_init_hw() call (which arguably could be optimized out)

Everything is fine in that case. With commit 62469c76, we would have
the following scenario to happen after an ifconfig down then up
sequence:

- bcmgenet_close() calls phy_disonnect() which makes dev->phydev become
  NULL

- when bcmgenet_open() executes again and calls bcmgenet_mii_reset() from
  bcmgenet_power_up() to initialize the internal PHY, the NULL check
  becomes true, so we do not reset the PHY, yet we keep going on and
  initialize the UniMAC, causing MAC activity to occur

- we call bcmgenet_mii_reset() from bcmgenet_mii_probe(), but this is
  too late, the PHY is botched, and causes the above bogus pings/packets
  transmission/reception to occur
Reported-by: NJaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NPhilippe Reynes <tremyfr@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0299b6ac
    • P
      Revert "net: ethernet: bcmgenet: use new api ethtool_{get|set}_link_ksettings" · 62c8d3da
      由 Philippe Reynes 提交于 
      This reverts commit 6b352ebc ("net: ethernet: broadcom: bcmgenet:
use new api ethtool_{get|set}_link_ksettings").

We needs to revert the commit 62469c76 ("net: ethernet: bcmgenet:
use phydev from struct net_device"), because this commit add a
regression. As the commit 6b352ebc ("net: ethernet: broadcom:
bcmgenet: use new api ethtool_{get|set}_link_ksettings") depend
on the first one, we also need to revert it first.
Signed-off-by: NPhilippe Reynes <tremyfr@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62c8d3da
    • M
      bpf: Set register type according to is_valid_access() · 1955351d
      由 Mickaël Salaün 提交于 
      This prevent future potential pointer leaks when an unprivileged eBPF
program will read a pointer value from its context. Even if
is_valid_access() returns a pointer type, the eBPF verifier replace it
with UNKNOWN_VALUE. The register value that contains a kernel address is
then allowed to leak. Moreover, this fix allows unprivileged eBPF
programs to use functions with (legitimate) pointer arguments.

Not an issue currently since reg_type is only set for PTR_TO_PACKET or
PTR_TO_PACKET_END in XDP and TC programs that can only be loaded as
privileged. For now, the only unprivileged eBPF program allowed is for
socket filtering and all the types from its context are UNKNOWN_VALUE.
However, this fix is important for future unprivileged eBPF programs
which could use pointers in their context.
Signed-off-by: NMickaël Salaün <mic@digikod.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1955351d