lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 26 Apr 2016 23:24:54 +0200
From:	Joachim Eastwood <manabian@...il.com>
To:	davem@...emloft.net
Cc:	Joachim Eastwood <manabian@...il.com>, marex@...x.de,
	dinguyen@...nsource.altera.com, peppe.cavallaro@...com,
	alexandre.torgue@...com, netdev@...r.kernel.org
Subject: [PATCH net-next 0/5] stmmac: dwmac-socfpga refactor+cleanup

This patch aims to remove the init/exit callbacks from the dwmac-
socfpga driver and instead use standard PM callbacks. Doing this
will also allow us to cleanup the driver.

Eventually the init/exit callbacks will be deprecated and removed
from all drivers dwmac-* except for dwmac-generic. Drivers will be
refactored to use standard PM and remove callbacks.

This patch set should not change the behavior of the driver itself,
it only moves code around. The only exception to this is patch
number 4 which restores the resume callback behavior which was
changed in the "net: stmmac: socfpga: Remove re-registration of
reset controller" patch. I belive calling phy_resume() only
from the resume callback and not probe is the right thing to do.


Couple of heads-up here:
 1. This patch set depend on Marek's "Remove re-registration of
    reset controller" patch [1] which is not in net-next yet.
    Without that patch this set will not apply!

 2. The first patch changes the prototype of a couple of
    functions used in Alexandre's "add Ethernet glue logic for
    stm32 chip" patch [2] and will cause build failures for
    dwmac-stm32.c if not fixed up!
    If Alexandre's patch set is applied first I will gladly
    rebase my patch set to account for his driver as well.

So at the moment there are issues here :/

I guess one way of handing this would just be wait for all
the bits to come together in net-next and resend.

Dave: Please let me know if you have any preferred way of
      handling this.


[1] https://patchwork.ozlabs.org/patch/613085/
[2] https://patchwork.ozlabs.org/patch/614405/


Joachim Eastwood (5):
  stmmac: let remove/resume/suspend functions take device pointer
  stmmac: dwmac-socfpga: add PM ops and resume function
  stmmac: dwmac-socfpga: keep a copy of stmmac_rst in driver priv data
  stmmac: dwmac-socfpga: call phy_resume() only in resume callback
  stmmac: dwmac-socfpga: kill init() and rename setup() to set_phy_mode()

 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c    | 106 +++++++++++----------
 drivers/net/ethernet/stmicro/stmmac/stmmac.h       |   6 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  15 +--
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c   |  24 +----
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   6 +-
 5 files changed, 71 insertions(+), 86 deletions(-)

-- 
2.8.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ