Skip to content

L
linux
Switch branch/tag
  1. 30 Sep, 2016 9 commits
  3. 29 Sep, 2016 6 commits
    • David S. Miller's avatar
      Merge branch 'qcom-emac-acpi' · 31fbe81f
      David S. Miller authored 
      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: default avatarDavid S. Miller <davem@davemloft.net>
      31fbe81f
    • Timur Tabi's avatar
      net: qcom/emac: initial ACPI support · 5f3d3807
      Timur Tabi authored 
      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: default avatarTimur Tabi <timur@codeaurora.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f3d3807
    • Timur Tabi's avatar
      net: qcom/emac: use device_get_mac_address · 0de709ac
      Timur Tabi authored 
      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: default avatarTimur Tabi <timur@codeaurora.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0de709ac
    • Timur Tabi's avatar
      net: qcom/emac: do not use devm on internal phy pdev · 54e19bc7
      Timur Tabi authored 
      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: default avatarTimur Tabi <timur@codeaurora.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54e19bc7
    • Josef Bacik's avatar
      bpf: allow access into map value arrays · 48461135
      Josef Bacik authored 
      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: default avatarJosef Bacik <jbacik@fb.com>
Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48461135
    • Eric Dumazet's avatar
      net: do not export sk_stream_write_space · 7836667c
      Eric Dumazet authored 
      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: default avatarDavid S. Miller <davem@davemloft.net>
      7836667c
  5. 28 Sep, 2016 18 commits
  7. 27 Sep, 2016 7 commits
    • jbaron@akamai.com's avatar
      bnx2x: free the mac filter group list before freeing the cmd · e96e0ede
      jbaron@akamai.com authored 
      The group list must be freed prior to freeing the command otherwise
we have a use-after-free.
Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
Cc: Yuval Mintz <Yuval.Mintz@qlogic.com>
Cc: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e96e0ede
    • David S. Miller's avatar
      Merge branch 'mediatek-pdam-lro-fixes' · 44675a6d
      David S. Miller authored 
      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: default avatarDavid S. Miller <davem@davemloft.net>
      44675a6d
    • Nelson Chang's avatar
      net: ethernet: mediatek: bug fix to disable HW LRO · ca3ba106
      Nelson Chang authored 
      (1) Modify the register settings for LRO relinquishments
(2) Jump out from the waiting loop while LRO relinquishments are done
Signed-off-by: default avatarNelson Chang <nelson.chang@mediatek.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca3ba106
    • Nelson Chang's avatar
      net: ethernet: mediatek: add to stop PDMA while stopping the frame engine · 6bf563d5
      Nelson Chang authored 
      Stop PDMA while the frame engine is going to stop.
Signed-off-by: default avatarNelson Chang <nelson.chang@mediatek.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6bf563d5
    • David S. Miller's avatar
      Merge branch 'bcmgenet-phydev-revert' · 3783c09e
      David S. Miller authored 
      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: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3783c09e
    • Philippe Reynes's avatar
      net: bcmgenet: use new api ethtool_{get|set}_link_ksettings · fa92bf04
      Philippe Reynes authored 
      The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
Signed-off-by: default avatarPhilippe Reynes <tremyfr@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa92bf04
    • Florian Fainelli's avatar
      Revert "net: ethernet: bcmgenet: use phydev from struct net_device" · 0299b6ac
      Florian Fainelli authored 
      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: default avatarJaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarPhilippe Reynes <tremyfr@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0299b6ac
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7