FogBugz #236669: Add a Kconfig for ILC driver

Without a Kconfig option, there's really no way to build the driver.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
FogBugz #237341: fix fetching cpu1start_addr for SMP

When CPU1 is brought out of reset, it's MMU is not turned on yet, so it
will only be able to use physical addresses. For systems that have their
MMU page configured for 0xC0000000, 0x80000000, or 0x40000000
"BIC 0x40000000" will work just fine, as it was just converting the
virtual address of &cpu1start_addr into a physical address, ie. 0xC0000000
became 0x80000000. So for systems where the SDRAM controller was able to do
a wrap-around access, this was working fine, as it was just dropping the
MSB, but for systems where out of bounds memory access is not allowed, this
would not allow CPU1 to correctly fetch &cpu1start_addr.

This patch fixes the secondary_trampoline code to correctly fetch the
physical address of cpu1start_addr directly. The patch will grab the
correct PAGE_OFFSET and convert &cpu1start_addr to the physical address
correctly.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
mtd: m25p80: Fix 4 byte addressing mode for Micron devices.

According to the datasheet for Micron n25q256a (N25Q256A13ESF40F) 4-byte
addressing mode should be entered as follows:

<quote>
To enter or exit the 4-byte address mode, the WRITE ENABLE command
must be executed to set the write enable latch bit to 1. (Note: The
WRITE ENABLE command must NOT be executed on the N25Q256A83ESF40x and
N25Q256A83E1240x devices.) S# must be driven LOW. The effect of the
command is immediate; after the command has been executed, the write
enable latch bit is cleared to 0.
</quote>

Micron's portable way to perform this for all types of Micron flash
is to first issue a write enable, then switch the addressing mode
followed by a write disable to avoid leaving the flash in a write-
able state.

Signed-off-by: Elie De Brauwer <eliedebrauwer@email.com>
[Brian: reworked a bit]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

Conflicts:
	drivers/mtd/devices/m25p80.c

Signed-off-by: Graham Moore <grmoore@opensource.altera.com>
net: stmmac: Change MAC interface to support multiple filter configurations

FogBugz #239490-1: Backported from Dave Miller's Net-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git,
commit ID 7ed24bbe188e9e910274969e65b91342e7642dbf, git tree tag
v3.16-rc7-1518-g7ed24bb.

The synopsys EMAC can be configured for different numbers of multicast hash
bins and perfect filter entries at device creation time and there's no way
to query this configuration information at runtime. As a result, a devicetree
parameter is required in order for the driver to program these filters
correctly for a particular device instance. This patch modifies the
10/100/1000 MAC software interface such that these configuration parameters
can be set at initialization time.

Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: stmmac: Correct set_filter for multicast and unicast cases

FogBugz #239490-2: Backported from Dave Miller's Net-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git,
commit ID aefef4c15a1f696ed6c676698d26741024d98f36, git tree tag
v3.16-rc7-1519-gaefef4c.

This patch removes the check for the number of mulitcast addresses
when using hash based filtering since it's not necessary. If the number
of multicast addresses in the list exceeds the number of multicast hash
bins, the bins will "fold" over into one of the bins configured and
enabled for the particular component instance.

The default number of maximum unicast addresses was changed from 32 to 1
since this number is not dependent on the component revision. The maximum
number of multicast and unicast addresses is dependent on the configuration
of the Synopsys EMAC configured by the SOC architect at the time the
features were selected and configured for a particular component. Sadly,
Synopsys does not provide a way to query the precise number supported
by a particular component, so we must fall back on a devicetree entry.
This configuration could vary from vendor to vendor (such as STMicro,
Altera, etc).

The multicast bins are set for every possible filtering case (including
no entries) - previously the bits were set only if multicast filter entries
were present.

Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dts: Add bindings for multicast hash bins and perfect filter entries

FogBugz #239490-3: Backported from Dave Miller's Net-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git,
commit ID 94ceaa26320fc48c16ea299ee7b546a0203d95b5, git tree tag
v3.16-rc7-1520-g94ceaa2.

This change adds bindings for the number of multicast hash bins and perfect
filter entries supported by the Synopsys EMAC. The Synopsys EMAC core is
configurable at device creation time, and can be configured for a different
number of multicast hash bins and a different number of perfect filter
entries. The device does not provide a way to query these parameters,
therefore parameters are required. The Altera Cyclone V SOC has support for
256 multicast hash bins and 128 perfect filter entries, and is different
than what's currently provided in the stmmac driver.

Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
ARM: socfpga: Add socfpga Ethernet filter attributes entries

FogBugz #239490-4: Backported from Dave Miller's Net-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git,
commit ID ea6856e35240c5accf0936de920f2d8c9afee444, git tree tag
v3.16-rc7-1521-gea6856e.

This patch adds socfpga Ethernet filter attributes for multicast
and unicast filters per Synopsys Ethernet IP configuration chosen
by Altera for the Cyclone 5 and Arria SOC FPGAs.

Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: stmmac: Support devicetree configs for mcast and ucast filter entries

FogBugz #239490-5: Backported from Dave Miller's Net-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git,
commit ID 3b57de958e2aa39abe020eb31bf19000d5899389, git tag
v3.16-rc7-1522-g3b57de9.

This patch adds and modifies code to support multiple Multicast and Unicast
Synopsys MAC filter configurations. The default configuration is defined to
support legacy driver behavior, which is 64 Multicast bins. The Unicast
filter code previously assumed all controllers support 32 or 16 Unicast
addresses based on controller version number, but this has been corrected
to support a default of 1 Unicast address. The filter configuration may
be specified through the devicetree using a Synopsys specific device tree
entry. This information was verified with Synopsys through
Synopsys Support Case #8000684337 and shared with the maintainer.

Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
stmmac: correct mc_filter local variable in set_filter and set_mac_addr call

FogBugz #239490-6: Backported from Dave Miller's Net-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git,
commit ID 3dab99e0b37e16525949757f46e33fb9612c73ec, git tag
v3.17-5527-g3dab99e.

Testing revealed that the local variable mc_filter was dimensioned
incorrectly for all possible configurations and get_mac_addr should
have been set_mac_addr (a typo). Make sure mc_filter is dimensioned
to 8 32-bit unsigned longs - the largest size of the Synopsys
multicast filter register set.

Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: phy: Adding SGMII support for Marvell 88ee1145 driver

Additional code to m88e1145_config_init function to allow the driver to
support SGMII mode.

Signed-off-by: Viet Nga Dao <vndao@altera.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
FogBugz #236745: Add SGMII support to socfpga

This patch adds SGMII support for  Altera socfpga Ethernet controller.
GMII to SGMII adapter is a soft IP core in FPGA system that converts
GMII interface from Synopsys MAC to SGMII interface. This adapter
consists of splitter, adapter buffer and TSE PCS. Software needs to
initialize the TSE PCS and adapter buffer at init state. Besides,
software also needs to configure tse pcs, splitter and enable/disable
adapter buffer properly when there is speed change.

Signed-off-by: Viet Nga Dao <vndao@altera.com>

---
V2:
  - Fix syntax issues
  - Add 2 files (dwmac-socfpga.c/h) to manage Altera specific additions
    to the stmmac driver such as GMII to RGMII and GMII to SGMII adapter
    as well as speed change management.

V3:
  - Remove the defined functions in header file (dwmac-socfpga.h)
  - Rename the struct plat_bsp_priv to dwmac_plat_priv
  - Add kfree(bsp_priv) before exit

V4:
  - Merge 2 functions sgmii_buffer_ena and sgmii_buffer_disable into
    one function called config_tx_buffer
  - Change function named config_adapter to adapter_config
  - Add some parameters for speed, duplex in header file
  - Rearrange includes in alphabet order

V5:
  - Add checking the return value of function adapter_init in socfpga.c

V6:
  - Change pr_info to pr_debug
FogBugz #243952: Missing Linefeed in SGMII Adapter Driver

This patch adds missing linefeed character at some pr_debug and pr_err
functions in dwmac-socfpga.c file of SGMII adapter driver.

Signed-off-by: Viet Nga Dao <vndao@altera.com>
FogBugz #243939: SGMII Design Example Intermittent Autonego Failure

This patch fixes the intermittent issue that autonego between TSE
and PHY does not complete when switching speed. This is done by
fixing the wrong TSE_PCS_SW_RESET_MASK value and adding restart
autonego action plus software reset when autonego does not
complete after 20ms.

Signed-off-by: Viet Nga Dao <vndao@altera.com>
drivercore: deferral race condition fix

When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.

The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.

The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:

...
[   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
[   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
[   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
[   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[   13.346755] davinci_mcasp_driver_init: LEAVE
[   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[   13.592527] platform sound.3: really_probe: probe_count = 0

In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.

The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.

This way we can avoid drivers stuck in the deferred queue.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Stable <stable@vger.kernel.org> # v3.4+
drivers/base/dd.c incorrect pr_debug() parameters

pr_debug() parameters are reverse order of format string

Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge remote-tracking branch 'upstream/socfpga-3.10-ltsi' into socfpga-3.10-ltsi

Conflicts:
	arch/arm/mach-socfpga/socfpga.c