Age | Commit message (Collapse) | Author |
|
Instead of doing error handling in the middle of ->probe(), move error
handling and freeing the reference to timer to the end.
This fixes a resource leak as dm_timer wasn't freed when allocating
*omap failed.
Implementation note: The put: label was never reached without a goto and
ret being unequal to 0, so the removed return statement is fine.
Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
In the old code (e.g.) mutex_destroy() was called before
pwmchip_remove(). Between these two calls it is possible that a PWM
callback is used which tries to grab the mutex.
Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
This allows to log all calls to the driver's lowlevel functions which
simplifies debugging in some cases.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
When .apply() is called with state->duty_cycle = 0 the duty_ns parameter
to rcar_pwm_set_counter() is 0 which results in ph being 0 and
rcar_pwm_set_counter() returning -EINVAL.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
pwm_get_state has no side effects and the resulting pwm_state is unused.
So drop the call to pwm_get_state() and the local variable from
rcar_pwm_apply().
The call was introduced in commit 7f68ce8287d3 ("pwm: rcar: Add support
"atomic" API") and already then was useless.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
This patch is to fix a serious issue that clock is always disabled
in esdhc_of_set_clock().
Fixes: 1b21a701aed9 ("mmc: sdhci-of-esdhc: fix clock setting for different controller versions")
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Link: https://lore.kernel.org/r/20200120094835.28050-1-yangbo.lu@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The standard SD controller uses two 16-bit registers for
command sending.
0xC: Transfer Mode Register
0xE: Command Register
But the eSDHC controller uses one 32-bit register instead.
0xC: XFERTYPE
For Transfer Mode Register and Command Register writing,
the eSDHC driver will store Transfer Mode Register value in
a variable first. When Command Register writing happens,
driver will directly write a 32-bit value into XFERTYPE
register.
But for Transfer Mode Register reading, driver just returns
a actual value. This may cause issue for some read-modify-write
operations. We should make both reading and write on that variable
for Transfer Mode Register.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Link: https://lore.kernel.org/r/20200117063858.37296-1-yangbo.lu@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
When switching from any MMC speed mode that requires 1.8v
(HS200, HS400 and HS400ES) to High Speed (HS) mode, the system
ends up configured for SDR12 with a 50MHz clock which is an illegal
mode.
This happens because the SDHCI_CTRL_VDD_180 bit in the
SDHCI_HOST_CONTROL2 register is left set and when this bit is
set, the speed mode is controlled by the SDHCI_CTRL_UHS field
in the SDHCI_HOST_CONTROL2 register. The SDHCI_CTRL_UHS field
will end up being set to 0 (SDR12) by sdhci_set_uhs_signaling()
because there is no UHS mode being set.
The fix is to change sdhci_set_uhs_signaling() to set the
SDHCI_CTRL_UHS field to SDR25 (which is the same as HS) for
any switch to HS mode.
This was found on a new eMMC controller that does strict checking
of the speed mode and the corresponding clock rate. It caused the
switch to HS400 mode to fail because part of the sequence to switch
to HS400 requires a switch from HS200 to HS before going to HS400.
This issue was previously fixed by commit c894e33ddc191 ("mmc: sdhci:
Fix incorrect switch to HS mode") and later removed by commit
07bcc411567c ("Revert \"mmc: sdhci: Fix incorrect switch to HS mode\"")
because it caused failures with some SD cards on AM65X systems. The
fix will now be done in a platform specific callback instead of
common sdhci code.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200113210706.11972-7-alcooperx@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The latest Arasan controller first used in the 7216 now supports
CQE so enable this feature.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Link: https://lore.kernel.org/r/20200113210706.11972-6-alcooperx@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Shutdown controller and disable it's clocks to insure max power
savings in S5 on systems that leave power on.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Link: https://lore.kernel.org/r/20200113210706.11972-5-alcooperx@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The new SCMI clock protocol driver does not get probed that early in
boot. Brcmstb drivers typically have the following code when getting
a clock:
priv->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(&pdev->dev, "Clock not found in Device Tree\n");
priv->clk = NULL;
}
This commit changes the driver to do what is below.
priv->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(priv->clk)) {
if (PTR_ERR(priv->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_err(&pdev->dev, "Clock not found in Device Tree\n");
priv->clk = NULL;
}
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Link: https://lore.kernel.org/r/20200113210706.11972-4-alcooperx@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The latest eMMC JEDEC specification version 5.1 added a new
transfer mode, HS400 with enhanced strobe (HS400ES). This mode
will be selected if both the host controller and eMMC device
support it. The latest Arasan 5.1 controller in the 7216a0
supports this mode. The "Host Controller Specification" has
not been updated so the controller register bit used to enable
this mode is not specified and varies the with controller vendor.
The Linux SDHCI driver supplies a callback for enabling HS400ES
mode and that callback will be used to supply a routine that
will set the proper bit in the Arasan Vendor register.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Link: https://lore.kernel.org/r/20200113210706.11972-3-alcooperx@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Currently MMC core disregards host->f_max during card initialization
phase. Obey upper boundary for the clock frequency and skip faster
speeds when they are above the limit.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/f471bceaf237d582d746bd289c4c4f3639cb7b45.1577962382.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
platform_get_irq() will call dev_err() itself on failure,
so there is no need for the driver to also do this.
This is detected by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116144322.57308-1-yuehaibing@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Fix an issue reported by sparse, since mixed types of parameters are
used on calling dmaengine_prep_slave_sg().
Fixes: 36e1da441fec (mmc: sdhci: add support for using external DMA devices)
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200120033223.897-1-zhang.chunyan@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
We currently have a hidden dependency to the device tree node name for
the clkctrl clocks. Instead of using standard node name like "clock", we
must use "l4-per-clkctrl" type naming so the clock driver can find the
associated clock domain. Further, if "clk" is specified for a clock node
name, the driver sets TI_CLK_CLKCTRL_COMPAT flag that uses different
logic for the clock name based on the parent node name for the all the
clkctrl clocks for the SoC.
If the clock node naming dependency is not understood, the related
clockdomain is not found, or a wrong one can get used if a clock manager
has multiple clock domains.
As each clkctrl instance represents a single clock domain, let's allow
using domain specific compatible names to specify the clock domain.
This simplifies things and removes the hidden dependency to the node
name. And then later on, after the node names have been standardized,
we can drop the related code for parsing the node names.
Let's also update the binding to use standard "clock" node naming
instead of "clk" and add the missing description for reg.
Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Replace rtl8169_ioctl with new generic function phy_do_ioctl.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
A number of network drivers has the same glue code to use phy_mii_ioctl
as ndo_do_ioctl handler. So let's add such a generic ndo_do_ioctl
handler to phylib.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
|
|
The N56VB laptop has a round button located on the left side above the
keyboard. Map it to F13 since it does not have any predeterminated
purpose.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
To discover core-power capability, some new mailbox commands are added. Allow
those commands to execute.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
For SDHCIv3+ with programmable clock mode, minimal clock frequency is
still base clock / max(divider). Minimal programmable clock frequency is
always greater than minimal divided clock frequency. Without this patch,
SDHCI uses out-of-spec initial frequency when multiplier is big enough:
mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz
[for 480 MHz source clock divided by 1024]
The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode.
Fixes: c3ed3877625f ("mmc: sdhci: add support for programmable clock mode")
Cc: <stable@vger.kernel.org> # 4f6aa3264af4: mmc: tegra: Only advertise UHS modes if IO regulator is present
Cc: <stable@vger.kernel.org>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Some omap controllers need software to monitor a 0->1->0 for software
reset. Add a SDHCI_OMAP_SPECIAL_RESET flag to indicate this.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-11-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Add support for new compatible for TI's am335x and am437x devices.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-10-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Disable data timeout interrupt during an erase operation.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-8-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Refactor sdhci_set_timeout() such that platform drivers can do some
functionality in a set_timeout() callback and then call
__sdhci_set_timeout() to complete the operation.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-7-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Export sdhci_set_timeout_irq() so that it is accessible from platform drivers.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-6-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
sdhci-omap can support both external dma controller via dmaengine framework
as well as ADMA which standard SD host controller provides.
Fixes by Faiz Abbas <fazi_abbas@ti.com>:
1. Switch to DMA slave mode when using external DMA
2. Add offset to mapbase
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-5-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Some standard SD host controllers can support both external dma
controllers as well as ADMA/SDMA in which the SD host controller
acts as DMA master. TI's omap controller is the case as an example.
Currently the generic SDHCI code supports ADMA/SDMA integrated in
the host controller but does not have any support for external DMA
controllers implemented using dmaengine, meaning that custom code is
needed for any systems that use an external DMA controller with SDHCI.
Fixes by Faiz Abbas <faiz_abbas@ti.com>:
1. Map scatterlists before dmaengine_prep_slave_sg()
2. Use dma_async() functions inside of the send_command() path and call
terminate_sync() in non-atomic context in case of an error.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-4-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
In preparation for adding external dma support, factor out data initialization,
block info and mrq_done to their own functions.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Tested-by: Baolin Wang <baolin.wang7@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-3-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The SERDES statistics are valid for all members of the 6390 family,
not just the 6390 itself. Add the needed callbacks to all members of
the family.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
USXGMII supports passing link information in-band between PHY and MAC PCS,
add it to the list of protocols that support in-band AN mode.
Being a MAC-PHY protocol that can auto-negotiate link speeds up to 10
Gbps, we populate the initial supported mask with the entire spectrum of
link modes up to 10G that PHYLINK supports, and we let the driver reduce
that mask in its .phylink_validate method.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add support for hierarchical irq domains. This is needed as
pre-requisite for gpio-sifive driver.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1575976274-13487-4-git-send-email-yash.shah@sifive.com
|
|
Make use of newly introduced irq_domain_translate_onecell() instead of
custom made function.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1575976274-13487-3-git-send-email-yash.shah@sifive.com
|
|
The APIs can be used by Ethernet drivers without actually loading a PHY
driver. This may become more widespread in the future with 802.3z
compatible MAC PCS devices being locally driven by the MAC driver when
configuring for a PHY mode with in-band negotiation.
Check that drv is not NULL before reading from it.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
For some reason, PHYLINK does not put the copper modes for 802.3bz
(NBASE-T) and 802.3an-2006 (10GBASE-T) in the PHY's supported mask, when
the PHY-MAC connection is a 10G-capable one (10GBase-KR, 10GBase-R,
USXGMII). One possible way through which the cable side can work at the
lower speed is by having the PHY emit PAUSE frames towards the MAC. So
fix that omission.
Also include the 2500Base-X fiber mode in this list while we're at it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
snps databook noted that physical coding sublayer (PCS) interface
that can be used when the MAC is configured for the TBI, RTBI, or
SGMII PHY interface. we have RGMII and SGMII in a SoC and it also
has the PCS block. it needs stmmac_init_phy and stmmac_mdio_register
function for initializing phy when it used RGMII interface.
Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
brcm_avs_cpufreq_get() calls cpufreq_cpu_get() to get the cpufreq
policy, meanwhile, it also increments the kobject reference count
to mark it busy. However, a corresponding call of cpufreq_cpu_put()
is ignored to decrement the kobject reference count back, which may
lead to a potential stuck risk that the cpuhp thread deadly waits
for dropping of kobject refcount when cpufreq policy free.
With this patch, the cpuhp thread can be easily exercised by
attempting to force an unbind of the CPUfreq driver.
Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
[ Viresh: Dropped !policy check ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
This is similar to what we have for omap5 except the gpu_cm address is
different, the mux clocks have one more source option, and there's no
divider clock.
Note that because of the current dts node name dependency for mapping to
clock domain, we must still use "gpu-clkctrl@" naming instead of generic
"clock@" naming for the node. And because of this, it's probably best to
apply the dts node addition together along with the other clock changes.
For accessing the GPU, we also need to configure the interconnect target
module for GPU similar to what we have for omap5, I'll send that change
separately.
Cc: Benoit Parrot <bparrot@ti.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Robert Nelson <robertcnelson@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Looks like we're missing AESS clock for omap5. This is similar to what
omap4 has.
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Matthijs van Duin <matthijsvanduin@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
The parent clk for gmac clk ctrl has to be gmac_main_clk (125MHz) instead
of dpll_gmac_ck (1GHz). This is caused incorrect CPSW MDIO operation.
Hence, fix it.
Fixes: dffa9051d546 ('clk: ti: dra7: add new clkctrl data')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Add clkctrl data for VPE.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Add clkctrl data for CAM domain.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Dave noticed that when specifying multiple efi_fake_mem= entries only
the last entry was successfully being reflected in the efi memory map.
This is due to the fact that the efi_memmap_insert() is being called
multiple times, but on successive invocations the insertion should be
applied to the last new memmap rather than the original map at
efi_fake_memmap() entry.
Rework efi_fake_memmap() to install the new memory map after each
efi_fake_mem= entry is parsed.
This also fixes an issue in efi_fake_memmap() that caused it to litter
emtpy entries into the end of the efi memory map. An empty entry causes
efi_memmap_insert() to attempt more memmap splits / copies than
efi_memmap_split_count() accounted for when sizing the new map. When
that happens efi_memmap_insert() may overrun its allocation, and if you
are lucky will spill over to an unmapped page leading to crash
signature like the following rather than silent corruption:
BUG: unable to handle page fault for address: ffffffffff281000
[..]
RIP: 0010:efi_memmap_insert+0x11d/0x191
[..]
Call Trace:
? bgrt_init+0xbe/0xbe
? efi_arch_mem_reserve+0x1cb/0x228
? acpi_parse_bgrt+0xa/0xd
? acpi_table_parse+0x86/0xb8
? acpi_boot_init+0x494/0x4e3
? acpi_parse_x2apic+0x87/0x87
? setup_acpi_sci+0xa2/0xa2
? setup_arch+0x8db/0x9e1
? start_kernel+0x6a/0x547
? secondary_startup_64+0xb6/0xc0
Commit af1648984828 "x86/efi: Update e820 with reserved EFI boot
services data to fix kexec breakage" introduced more occurrences where
efi_memmap_insert() is invoked after an efi_fake_mem= configuration has
been parsed. Previously the side effects of vestigial empty entries were
benign, but with commit af1648984828 that follow-on efi_memmap_insert()
invocation triggers efi_memmap_insert() overruns.
Reported-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20191231014630.GA24942@dhcp-128-65.nay.redhat.com
Link: https://lore.kernel.org/r/20200113172245.27925-14-ardb@kernel.org
|
|
With efi_fake_memmap() and efi_arch_mem_reserve() the efi table may be
updated and replaced multiple times. When that happens a previous
dynamically allocated efi memory map can be garbage collected. Use the
new EFI_MEMMAP_{SLAB,MEMBLOCK} flags to detect when a dynamically
allocated memory map is being replaced.
Debug statements in efi_memmap_free() reveal:
efi: __efi_memmap_free:37: phys: 0x23ffdd580 size: 2688 flags: 0x2
efi: __efi_memmap_free:37: phys: 0x9db00 size: 2640 flags: 0x2
efi: __efi_memmap_free:37: phys: 0x9e580 size: 2640 flags: 0x2
...a savings of 7968 bytes on a qemu boot with 2 entries specified to
efi_fake_mem=.
[ ardb: added a comment to clarify that efi_memmap_free() does nothing when
called from efi_clean_memmap(), i.e., with data->flags == 0x0 ]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-13-ardb@kernel.org
|
|
In preparation for fixing efi_memmap_alloc() leaks, add support for
recording whether the memmap was dynamically allocated from slab,
memblock, or is the original physical memmap provided by the platform.
Given this tracking is established in efi_memmap_alloc() and needs to be
carried to efi_memmap_install(), use 'struct efi_memory_map_data' to
convey the flags.
Some small cleanups result from this reorganization, specifically the
removal of local variables for 'phys' and 'size' that are already
tracked in @data.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-12-ardb@kernel.org
|
|
In preparation for garbage collecting dynamically allocated EFI memory
maps, where the allocation method of memblock vs slab needs to be
recalled, convert the existing 'late' flag into a 'flags' bitmask.
Arrange for the flag to be passed via 'struct efi_memory_map_data'. This
structure grows additional flags in follow-on changes.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-11-ardb@kernel.org
|
|
A previous commit f99afd08a45f ("efi: Update efi_mem_type() to return an
error rather than 0") changed the return value from EFI_RESERVED_TYPE to
-EINVAL when the searched physical address is not present in any memory
descriptor. But the comment preceding the function never changed. Let's
change the comment now to reflect the new return value -EINVAL.
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-10-ardb@kernel.org
|
|
The new of_devlink support breaks PCIe probing on ARM platforms booting
via UEFI if the firmware exposes a EFI framebuffer that is backed by a
PCI device. The reason is that the probing order gets reversed,
resulting in a resource conflict on the framebuffer memory window when
the PCIe probes last, causing it to give up entirely.
Given that we rely on PCI quirks to deal with EFI framebuffers that get
moved around in memory, we cannot simply drop the memory reservation, so
instead, let's use the device link infrastructure to register this
dependency, and force the probing to occur in the expected order.
Co-developed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org
|