commit 5f9d1fde7d54a5(raid5: fix memory leak of bio integrity data)
moves bio_reset to bio_endio. But it introduces a small race condition.
It does bio_reset after raid5_release_stripe, which could make the
stripe reusable and hence reuse the bio just before bio_reset. Moving
bio_reset before raid5_release_stripe is called should fix the race.
Reported-and-tested-by: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
Signed-off-by: Shaohua Li <shli@fb.com>
Right now we are passing a pointer to a pointer to the structure that
will be used to fetch the clk hw, which gets casted later to a pointer
to the structure, thus getting garbage in the hw structs.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Fixes: a8b6e85db6 ("clk: rk808: Migrate to clk_hw based OF and
registration APIs")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
generic definition to smp_wmb() is not sufficient
- avoid a recursive loop with the graph tracer by using using
preempt_(enable|disable)_notrace in _percpu_(read|write)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJX0vFPAAoJEGvWsS0AyF7x1jsP/0PuYxMPfkBBrL6dKfcwsBXR
9eKhIui8gwkjtpvpeDMSia8+5V+UvFYhB/oaPS5tbSaP1DzS/1Uhmr8Nd17fEBZH
nJZfodCRISSy+kOIiEIMAb00pXrkJpgn4Fy6Yf5jgKjrUvLYkLaeNNR9WQ1Nrwbl
tOmK+974fTtRN+46Ht3vS4hX6kqSDr7Ze8ezFLZc5Nt1tS3R7D0gfVnE3DBQ+x9y
gg+01WvGa2K/Iz0ur7zZo5eLVV7L+JfFvkBQCNxfFMkSt8SzOR+i6bPzqTGjy9Ge
rW1l4GOCXw/Di2PfPvQ0+BpJx/HY4vjmEdItdKm1ZOySPqJkl08wOF2NFse2ZYka
cUC+vlZE7zDjoHVOVYgjYTJtXvBZnwakIZ9Oxhsjw3h93hGPOXrJF5y6uYLiMCJa
5yASzwX617hFBxO8VrIeqjVw7z2BLHLMiPE6uhiQ8TJiiwHXMxJzaVnBaGL0xidA
qPzn7DhAHUsEb3bxYixu5uA/uyvJ7l33iRjOSObTUWxtBxMEvgajnxh1rkMl7lfY
izCvwjtIU/1mAae3MA4qddzrxuPwp3GtmXC3Tb/rxzD4fgvkvqrGHrXyufeLYUWC
z40kuGyp5ZMxTArPbno6TurseXeIWJQOW9/ya28FLzNbHC7RenIHBl7bSyoDYnFu
RGCmr4g2q3hKG5pjJ+1P
=QLnH
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Catalin Marinas:
- smp_mb__before_spinlock() changed to smp_mb() on arm64 since the
generic definition to smp_wmb() is not sufficient
- avoid a recursive loop with the graph tracer by using using
preempt_(enable|disable)_notrace in _percpu_(read|write)
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: use preempt_disable_notrace in _percpu_read/write
arm64: spinlocks: implement smp_mb__before_spinlock() as smp_mb()
Return negative error code from the edac_mc_add_mc() error handling case
instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: York Sun <york.sun@nxp.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/1473350284-26482-1-git-send-email-weiyj.lk@gmail.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Add York as the maintainer so that get_maintainers.pl can find him on
patches.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: York Sun <york.sun@nxp.com>
Doug hasn't been active as a maintainer for a long time now. Move him to
CREDITS.
Thanks for all the hard work, Doug!
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Doug Thompson <norsk5@yahoo.com>
Cc: Doug Thompson <dougthompson@xmission.com>
The LSE atomics are implemented using alternative code sequences of
different lengths, and explicit NOP padding is used to ensure the
patching works correctly.
This patch converts the bulk of the LSE code over to using the __nops
macro, which makes it slightly clearer as to what is going on and also
consolidates all of the padding at the end of the various sequences.
Signed-off-by: Will Deacon <will.deacon@arm.com>
NOP sequences tend to get used for padding out alternative sections
and uarch-specific pipeline flushes in errata workarounds.
This patch adds macros for generating these sequences as both inline
asm blocks, but also as strings suitable for embedding in other asm
blocks directly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Similar to our {read,write}_sysreg accessors for architected, named
system registers, this patch introduces {read,write}_sysreg_s variants
that can take arbitrary sys_reg output and therefore access IMPDEF
registers or registers that unsupported by binutils.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Since its initial commit, the driver is buggy for multiple interrupts
handling. The translation from the former lubbock.c file was not
complete, and might stall all interrupt handling when multiple
interrupts occur.
This is especially true when inside the interrupt handler and if a new
interrupt comes and is not handled, leaving the output line still held,
and not creating a transition as the GPIO block behind would expect to
trigger another cplds_irq_handler() call.
For the record, the hardware is working as follows.
The interrupt mechanism relies on :
- one status register
- one mask register
Let's suppose the input irq lines are called :
- i_sa1111
- i_lan91x
- i_mmc_cd
Let's suppose the status register for each irq line is called :
- status_sa1111
- status_lan91x
- status_mmc_cd
Let's suppose the interrupt mask for each irq line is called :
- irqen_sa1111
- irqen_lan91x
- irqen_mmc_cd
Let's suppose the output irq line, connected to GPIO0 is called :
- o_gpio0
The behavior is as follows :
- o_gpio0 = not((status_sa1111 & irqen_sa1111) |
(status_lan91x & irqen_lan91x) |
(status_mmc_cd & irqen_mmc_cd))
=> this is a N-to-1 NOR gate and multiple AND gates
- irqen_* is exactly as programmed by a write to the FPGA
- status_* behavior is governed by a bi-stable D flip-flop
=> on next FPGA clock :
- if i_xxx is high, status_xxx becomes 1
- if i_xxx is low, status_xxx remains as it is
- if software sets status_xxx to 0, the D flip-flop is reset
=> status_xxx becomes 0
=> on next FPGA clock cycle, if i_xxx is high, status_xxx becomes
1 again
Fixes: fc9e38c0f4 ("ARM: pxa: lubbock: use new pxa_cplds driver")
Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
The init_irq and handle_irq can be declared through standard irqchip
declaration and are not necessary in machine descriptions.
This is another step towards the generic kernel for the pxa
architecture.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Arnd Bergmann <arnd@arndb.de>
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data type by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Magician has GPIO117_I2C_SCL and GPIO118_I2C_SDA pins declared twice.
Signed-off-by: Petr Cvek <petr.cvek@tul.cz>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
The commit 9bf448c66d ("ARM: pxa: use generic gpio operation instead of
gpio register") from Oct 17, 2011, leads to the following static checker
warning:
arch/arm/mach-pxa/spitz_pm.c:172 spitz_charger_wakeup()
warn: double left shift '!gpio_get_value(SPITZ_GPIO_KEY_INT)
<< (1 << ((SPITZ_GPIO_KEY_INT) & 31))'
As Dan reported, the value is shifted three times :
- once by gpio_get_value(), which returns either 0 or BIT(gpio)
- once by the shift operation '<<'
- a last time by GPIO_bit(gpio) which is BIT(gpio)
Therefore the calculation lead to a chained or operator of :
- (1 << gpio) << (1 << gpio) = (2^gpio)^gpio = 2 ^ (gpio * gpio)
It is be sheer luck the former statement works, only because each gpio
used is strictly smaller than 6, and therefore 2^(gpio^2) never
overflows a 32 bits value, and because it is used as a boolean value to
check a gpio activation.
As the xxx_charger_wakeup() functions are used as a true/false detection
mechanism, take that opportunity to change their prototypes from integer
return value to boolean one.
Fixes: 9bf448c66d ("ARM: pxa: use generic gpio operation instead of
gpio register")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
With the introduction of critical-clock support in v4.8, our developers'
default configuration is to run with 'clk_ignore_unused' removed. This
patch-set ensures they can achieve successful boot when a) booting from
an SD Card and when b) booting using USB->Eth adaptors for NFS booting.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJX0XH9AAoJEMrHeC97M/+mKo4QAJLsI+dcHn5vAhX8wqL0r2HJ
n2T0g8zCUZ+WkDybdgicRTfvhC59GZJ7x6T6i9I9iTNOzAifXGFnagdxzf9crUJ4
bMKP6RKNVNFWzaKE1Xt/gMGCGneLIv63ALhxNxcC8eDT49ws0qXqfP21NTXH1AVi
lFf238pEHpOV324lnziN879cpz/T8ZlYa61KCx+d5Od+xkzm5XBzLH8ZxzOAAKFY
WjgER1j3BZwDZhbsT03Z6F3TiiLrDwBKiARe7ccHnIwfdt0Mk4kjSznMZw4ZIH4d
2V/Rj0Id/MqBrODiw2EXyjA6YPCqJfr3y4wh+15AI+XUCfWEEWsrRfJvBxabFduJ
1pK3WjvEqZXCUE1ow6fUZ9bsVPNiGxSGKcdhI10CgEAuOBgbzBqQyTIty4hCGdn3
4k6Jpk1tXeOZC4Uzq9B28eL1viipyo0uOJdKNHEzXaah9QnwGQgD0spIhvKV4/TY
C3Ov+3eON0sUET4f/XCziNGi+1gF4YUOw0V6iX3rHT1UtDtRvGDznjS125wew1Xp
OXFINmYU3J6o8InF+SvPwfTbeZZBXlqJ/Q5EPFDHGe5q/cYF8wDvU4yTWeNzqjNj
ZOCcKakLZtiq4HfsbeUKX8m64hi+bFmsTIfTj99EgyB/PeCnoWnmHLM/cf94nDTf
Ltjajd2G8NPvzfeyp/Ys
=lGFr
-----END PGP SIGNATURE-----
Merge tag 'sti-dt-fixes-for-v4.8-rcs' of git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti into fixes
Pull "Handle STiH410 interconnect clock required for EHCI/OHCI and SDHCI" from Patrice Chotard:
With the introduction of critical-clock support in v4.8, our developers'
default configuration is to run with 'clk_ignore_unused' removed. This
patch-set ensures they can achieve successful boot when a) booting from
an SD Card and when b) booting using USB->Eth adaptors for NFS booting.
* tag 'sti-dt-fixes-for-v4.8-rcs' of git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti:
ARM: dts: STiH407-family: Provide interconnect clock for consumption in ST SDHCI
ARM: dts: STiH410: Handle interconnect clock required by EHCI/OHCI (USB)
The ../../../arm... style cross-references added by commit 9d56c22a78
("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the
context of the split device-tree repository[0] (where the directory
structure differs). As with commit 8ee57b8182 ("ARM64: dts: vexpress: Use
a symlink to vexpress-v2m-rs1.dtsi from arch=arm") use symlinks instead.
[0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Lee Jones <lee@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rpi-kernel@lists.infradead.org
Cc: arm@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This file is included from DTS files under arch/arm64 too (via
broadcom/bcm2837-rpi-3-b.dts and broadcom/bcm2837.dtsi). There is a desire
not to have skeleton.dtsi for ARM64. See commit 3ebee5a2e1 ("arm64: dts:
kill skeleton.dtsi") for rationale for its removal.
As well as the addition of #*-cells also requires adding the device_type to
the rpi memory node explicitly.
Note that this change results in the removal of an empty /aliases node from
bcm2835-rpi-a.dtb and bcm2835-rpi-a-plus.dtb. I have no hardware to check
if this is a problem or not.
It also results in some reordering of the nodes in the DTBs (the /aliases
and /memory nodes come later). This isn't supposed to matter but, again,
I've no hardware to check if it is true in this particular case.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Lee Jones <lee@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rpi-kernel@lists.infradead.org
Cc: arm@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes an idmap issue on 32-bit KVM on ARM, and fixes a memory unmapping
issue that we've had forever.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJX0pHmAAoJEEtpOizt6ddy1LcIAI0bolSI1veypr1jCE3rTqPU
3y0jnsOUDVYFWAG6g+fy8navkzwRxp9bgR4B9JZ35P/A0Te2vynajikf24ts/n2F
oKQ4p1gq8AninXLYCJNcnlJ2yaB8beHzdPzp++IyayI1gc9CGfSlHdltg5CID/lT
f5hMgrPv1n5tgD2wWZkqLTr84DQfEMopWg7ICgH3BgPwyS4ogs1/JJF4M+MN6nUP
lcAvukxnH62246dXsNOpjtubUmruK3ie16mqxCnRiT8uYnfS4JVsxLgHUqR6U/es
/0aASc0oRhzEafGFiVC6TtrZvkSirbBw363WnswFyfafXrF+4P6Vhd9KnqZ11MI=
=boFc
-----END PGP SIGNATURE-----
Merge tag 'kvm-arm-fixes-for-v4.8-round2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
KVM/ARM Fixes for v4.8, round 2
Fixes an idmap issue on 32-bit KVM on ARM, and fixes a memory unmapping
issue that we've had forever.
- Don't alias user region to other regions below PAGE_OFFSET from Paul Mackerras
- Fix again csum_partial_copy_generic() on 32-bit from Christophe Leroy
- Fix corrupted PE allocation bitmap on releasing PE from Gavin Shan
Fixes for code merged this cycle:
- Fix crash on releasing compound PE from Gavin Shan
- Fix processor numbers in OPAL ICP from Benjamin Herrenschmidt
- Fix little endian build with CONFIG_KEXEC=n from Thiago Jung Bauermann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJX0qKlAAoJEFHr6jzI4aWAu30QAK88plLxJ2z5Lyf7axdHf7P0
NfM6xQLyuUQ1xP3ksUB4/4eps3jINJ0bZRd4mMJ3fO/YgNsBACayB9GeE478tMbp
1KmK94qpLk1u4BUxXNtsWJLEuzVqAPr2cGh6jddmkPXGCUx1MFatEVNVJupX+Vt9
sJsmhLatUucZEQI6r4sK5wDOdLYIQgcgTIWW5qHH7jyJDKLGyJbNPtmQhbMWU0a5
zBwD+paecJSGTJEVjd3UwBic+oXt8chwiZkaHLu4Rh6JQ0yVRL4If4EYCodHIpDR
H7b0P9De9W6a+IWLjVDMhYKq9rBjjgZwcjMplkO7gBE2P+v/NGzbfORJtNXeOgKE
/RSWufpTbpiGyUzP1Lr/j0O59ZoijRGBK8zuha5FtsTlhl909ifc6KuHO5aqHY9r
I5o7ws+hSBM1u9cf0Bl011P4uToYzy1auMsZsjDW2SdDEFtJ+WK+0I2vp+M9Jv73
/F48n/EWUuul5oS2Uar+V2AUADpnYPRi50OR1zVJxdJSM8bZFue4brBFfx1bI/2/
jmK87hxNwJtYT45KiuEXr2FWMiB1iNHHxL/OEwWbitf2MfRjq8+LHbdt9FxOSj3/
+8cw3f1zyEjNsvH380HhkUBZknKmD7z8V5Ko5Dx5h8cuRlL+QEW2GnW+1NN7VMoQ
T7QTHRR4ziHSKdzAIlTe
=q0Jo
-----END PGP SIGNATURE-----
Merge tag 'powerpc-4.8-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
"Fixes marked for stable:
- Don't alias user region to other regions below PAGE_OFFSET from
Paul Mackerras
- Fix again csum_partial_copy_generic() on 32-bit from Christophe
Leroy
- Fix corrupted PE allocation bitmap on releasing PE from Gavin Shan
Fixes for code merged this cycle:
- Fix crash on releasing compound PE from Gavin Shan
- Fix processor numbers in OPAL ICP from Benjamin Herrenschmidt
- Fix little endian build with CONFIG_KEXEC=n from Thiago Jung
Bauermann"
* tag 'powerpc-4.8-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/mm: Don't alias user region to other regions below PAGE_OFFSET
powerpc/32: Fix again csum_partial_copy_generic()
powerpc/powernv: Fix corrupted PE allocation bitmap on releasing PE
powerpc/powernv: Fix crash on releasing compound PE
powerpc/xics/opal: Fix processor numbers in OPAL ICP
powerpc/pseries: Fix little endian build with CONFIG_KEXEC=n
This patch adds code instantiating the EPLL, which is used as the
audio subsystem's root clock.
The requirement to specify the external root clock in clocks property
is documented. Having the consumer 'clocks' property ensures proper
initialization order by explicitly specifying dependencies in DT.
It prevents situations when the SoC's clock controller driver has
initialized, the external oscillator clock is not yet registered
and setting clock frequencies through assigned-clock-rates property
doesn't work properly due to unknown external oscillator frequency.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
There is no need to log probe() completion in normal conditions
so the "setup completed" log is removed.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Exynos5410 Audio Subsystem Clock Controller, comparing to the already
supported IP block revisions, has additionally an I2S_MST divider
so a new compatible string is added.
It is not clear from the Exynos5410 User's Manual released on 2012.03.09
where in the clock tree the I2S_MST clock divider can be found exactly
so this clock is left unimplemented for now.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
There is no such significant differences in pll2550x PLL type
to justify a separate registration function. This patch adapts
exynos5440 driver to use the common function and removes
samsung_clk_register_pll2550x().
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
This patch adds the mux/divider clocks for CMU_CDREX (DRAM Express
Controller) which generates the clocks for DRAM and NoC (Network on Chip)
bus. There is differnet source of MUX_MX_MSPLL_CCORE between exynos5420
and exynos5422, so each MUX_MX_MSPLL_CCORE uses the different parent source
group.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
This patch uses the samsung_cmu_register_one() to simplify code
and move the pll/mux/div/gate data to initconst section.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
This patch moves the samsung_cmu_info struct instances to initconst
section, this decreases the kernel image size by 784 bytes, which makes
zImage smaller by 480 bytes.
The patch increases .init.rodata section size by 780 bytes but decreases
.init.text section size by 1564 bytes.
Size of the drivers/clk/samsung/clk-exynos5260.o object file is 29100
bytes without the patch and 28316 after applying the patch.
The section size differences are as below:
15c15
< 3 .init.text 000006b8 00000000 00000000 00000034 2**2
---
> 3 .init.text 0000009c 00000000 00000000 00000034 2**2
25c25
< 8 .init.rodata 00003f6c 00000000 00000000 00002f20 2**2
---
> 8 .init.rodata 00004278 00000000 00000000 00002904 2**2
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Pull ARM fixes from Russell King:
"A few ARM fixes:
- Robin Murphy noticed that the non-secure privileged entry was
relying on undefined behaviour, which needed to be fixed.
- Vladimir Murzin noticed that prov-v7 fails to build for MMUless
configurations because a required header file wasn't included.
- A bunch of fixes for StrongARM regressions found while testing
4.8-rc on such platforms"
* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
ARM: sa1100: clear reset status prior to reboot
ARM: 8600/1: Enforce some NS-SVC initialisation
ARM: 8599/1: mm: pull asm/memory.h explicitly
ARM: sa1100: register clocks early
ARM: sa1100: fix 3.6864MHz clock
We currently allow invocation of 8 boot services with efi_call_early().
Not included are LocateHandleBuffer and LocateProtocol in particular.
For graphics output or to retrieve PCI ROMs and Apple device properties,
we're thus forced to use the LocateHandle + AllocatePool + LocateHandle
combo, which is cumbersome and needs more code.
The ARM folks allow invocation of the full set of boot services but are
restricted to our 8 boot services in functions shared across arches.
Thus, rather than adding just LocateHandleBuffer and LocateProtocol to
struct efi_config, let's rework efi_call_early() to allow invocation of
arbitrary boot services by selecting the 64 bit vs 32 bit code path in
the macro itself.
When compiling for 32 bit or for 64 bit without mixed mode, the unused
code path is optimized away and the binary code is the same as before.
But on 64 bit with mixed mode enabled, this commit adds one compare
instruction to each invocation of a boot service and, depending on the
code path selected, two jump instructions. (Most of the time gcc
arranges the jumps in the 32 bit code path.) The result is a minuscule
performance penalty and the binary code becomes slightly larger and more
difficult to read when disassembled. This isn't a hot path, so these
drawbacks are arguably outweighed by the attainable simplification of
the C code. We have some overhead anyway for thunking or conversion
between calling conventions.
The 8 boot services can consequently be removed from struct efi_config.
No functional change intended (for now).
Example -- invocation of free_pool before (64 bit code path):
0x2d4 movq %ds:efi_early, %rdx ; efi_early
0x2db movq %ss:arg_0-0x20(%rsp), %rsi
0x2e0 xorl %eax, %eax
0x2e2 movq %ds:0x28(%rdx), %rdi ; efi_early->free_pool
0x2e6 callq *%ds:0x58(%rdx) ; efi_early->call()
Example -- invocation of free_pool after (64 / 32 bit mixed code path):
0x0dc movq %ds:efi_early, %rax ; efi_early
0x0e3 cmpb $0, %ds:0x28(%rax) ; !efi_early->is64 ?
0x0e7 movq %ds:0x20(%rax), %rdx ; efi_early->call()
0x0eb movq %ds:0x10(%rax), %rax ; efi_early->boot_services
0x0ef je $0x150
0x0f1 movq %ds:0x48(%rax), %rdi ; free_pool (64 bit)
0x0f5 xorl %eax, %eax
0x0f7 callq *%rdx
...
0x150 movl %ds:0x30(%rax), %edi ; free_pool (32 bit)
0x153 jmp $0x0f5
Size of eboot.o text section:
CONFIG_X86_32: 6464 before, 6318 after
CONFIG_X86_64 && !CONFIG_EFI_MIXED: 7670 before, 7573 after
CONFIG_X86_64 && CONFIG_EFI_MIXED: 7670 before, 8319 after
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Commit 2c23b73c2d ("x86/efi: Prepare GOP handling code for reuse
as generic code") introduced an efi_is_64bit() macro to x86 which
previously only existed for arm arches. The macro is used to
choose between the 64 bit or 32 bit code path in gop.c at runtime.
However the code path that's going to be taken is known at compile
time when compiling for x86_32 or for x86_64 with mixed mode disabled.
Amend the macro to eliminate the unused code path in those cases.
Size of gop.o text section:
CONFIG_X86_32: 1758 before, 1299 after
CONFIG_X86_64 && !CONFIG_EFI_MIXED: 2201 before, 1406 after
CONFIG_X86_64 && CONFIG_EFI_MIXED: 2201 before and after
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus reuse the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data type by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Currently, memory regions are only recorded in the memblock memory table
if they have the EFI_MEMORY_WB memory type attribute set. In case the
region is of a reserved type, it is also marked as MEMBLOCK_NOMAP, which
will leave it out of the linear mapping.
However, memory regions may legally have the EFI_MEMORY_WT or EFI_MEMORY_WC
attributes set, and the EFI_MEMORY_WB cleared, in which case the region in
question is obviously backed by normal memory, but is not recorded in the
memblock memory table at all. Since it would be useful to be able to
identify any UEFI reported memory region using memblock_is_memory(), it
makes sense to add all memory to the memblock memory table, and simply mark
it as MEMBLOCK_NOMAP if it lacks the EFI_MEMORY_WB attribute.
While implementing this, let's refactor the code slightly to make it easier
to understand: replace is_normal_ram() with is_memory(), and make it return
true for each region that has any of the WB|WT|WC bits set. (This follows
the AArch64 bindings in the UEFI spec, which state that those are the
attributes that map to normal memory)
Also, replace is_reserve_region() with is_usable_memory(), and only invoke
it if the region in question was identified as memory by is_memory() in the
first place. The net result is the same (only reserved regions that are
backed by memory end up in the memblock memory table with the MEMBLOCK_NOMAP
flag set) but carried out in a more straightforward way.
Finally, we remove the trailing asterisk in the EFI debug output. Keeping it
clutters the code, and it serves no real purpose now that we no longer
temporarily reserve BootServices code and data regions like we did in the
early days of EFI support on arm64 Linux (which it inherited from the x86
implementation)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: James Morse <james.morse@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
This driver is used by the Firmware Test Suite (FWTS) for testing the UEFI
runtime interfaces readiness of the firmware.
This driver exports UEFI runtime service interfaces into userspace,
which allows to use and test UEFI runtime services provided by the
firmware.
This driver uses the efi.<service> function pointers directly instead of
going through the efivar API to allow for direct testing of the UEFI
runtime service interfaces provided by the firmware.
Details for FWTS are available from,
<https://wiki.ubuntu.com/FirmwareTestSuite>
Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
Cc: joeyli <jlee@suse.com>
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Commit 7b02d53e7852 ("efi: Allow drivers to reserve boot services forever")
introduced a new efi_mem_reserve to reserve the boot services memory
regions forever. This reservation involves allocating a new EFI memory
range descriptor. However, allocation can only succeed if there is memory
available for the allocation. Otherwise, error such as the following may
occur:
esrt: Reserving ESRT space from 0x000000003dd6a000 to 0x000000003dd6a010.
Kernel panic - not syncing: ERROR: Failed to allocate 0x9f0 bytes below \
0x0.
CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc5+ #503
0000000000000000 ffffffff81e03ce0 ffffffff8131dae8 ffffffff81bb6c50
ffffffff81e03d70 ffffffff81e03d60 ffffffff8111f4df 0000000000000018
ffffffff81e03d70 ffffffff81e03d08 00000000000009f0 00000000000009f0
Call Trace:
[<ffffffff8131dae8>] dump_stack+0x4d/0x65
[<ffffffff8111f4df>] panic+0xc5/0x206
[<ffffffff81f7c6d3>] memblock_alloc_base+0x29/0x2e
[<ffffffff81f7c6e3>] memblock_alloc+0xb/0xd
[<ffffffff81f6c86d>] efi_arch_mem_reserve+0xbc/0x134
[<ffffffff81fa3280>] efi_mem_reserve+0x2c/0x31
[<ffffffff81fa3280>] ? efi_mem_reserve+0x2c/0x31
[<ffffffff81fa40d3>] efi_esrt_init+0x19e/0x1b4
[<ffffffff81f6d2dd>] efi_init+0x398/0x44a
[<ffffffff81f5c782>] setup_arch+0x415/0xc30
[<ffffffff81f55af1>] start_kernel+0x5b/0x3ef
[<ffffffff81f55434>] x86_64_start_reservations+0x2f/0x31
[<ffffffff81f55520>] x86_64_start_kernel+0xea/0xed
---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x9f0
bytes below 0x0.
An inspection of the memblock configuration reveals that there is no memory
available for the allocation:
MEMBLOCK configuration:
memory size = 0x0 reserved size = 0x4f339c0
memory.cnt = 0x1
memory[0x0] [0x00000000000000-0xffffffffffffffff], 0x0 bytes on node 0\
flags: 0x0
reserved.cnt = 0x4
reserved[0x0] [0x0000000008c000-0x0000000008c9bf], 0x9c0 bytes flags: 0x0
reserved[0x1] [0x0000000009f000-0x000000000fffff], 0x61000 bytes\
flags: 0x0
reserved[0x2] [0x00000002800000-0x0000000394bfff], 0x114c000 bytes\
flags: 0x0
reserved[0x3] [0x000000304e4000-0x00000034269fff], 0x3d86000 bytes\
flags: 0x0
This situation can be avoided if we call efi_esrt_init after memblock has
memory regions for the allocation.
Also, the EFI ESRT driver makes use of early_memremap'pings. Therfore, we
do not want to defer efi_esrt_init for too long. We must call such function
while calls to early_memremap are still valid.
A good place to meet the two aforementioned conditions is right after
memblock_x86_fill, grouped with other EFI-related functions.
Reported-by: Scott Lawson <scott.lawson@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Register the debugfs node 'efi_page_tables' to allow the UEFI runtime
page tables to be inspected. Note that ARM does not have 'asm/ptdump.h'
[yet] so for now, this is arm64 only.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Julia reported that we may double free 'name' in efivarfs_callback(),
and that this bug was introduced by commit 0d22f33bc37c ("efi: Don't
use spinlocks for efi vars").
Move one of the kfree()s until after the point at which we know we are
definitely on the success path.
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Sylvain Chouleur <sylvain.chouleur@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
This is a simple change to add in the physical mappings as well as the
virtual mappings in efi_map_region_fixed. The motivation here is to
get access to EFI runtime code that is only available via the 1:1
mappings on a kexec'd kernel.
The added call is essentially the kexec analog of the first __map_region
that Boris put in efi_map_region in commit d2f7cbe7b2 ("x86/efi:
Runtime services virtual mapping").
Signed-off-by: Alex Thorlton <athorlton@sgi.com>
Cc: Russ Anderson <rja@sgi.com>
Cc: Dimitri Sivanich <sivanich@sgi.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
No need to calculate the string length on every loop iteration.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
The dma_pool_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Mike Waychison <mikew@google.com>
Cc: Michel Lespinasse <walken@google.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Although very unlikey, if size is too small or zero, then we end up with
status not being set and returning garbage. Instead, initializing status to
EFI_INVALID_PARAMETER to indicate that size is invalid in the calls to
setup_uga32 and setup_uga64.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
The purpose of the efi_runtime_lock is to prevent concurrent calls into
the firmware. There is no need to use spinlocks here, as long as we ensure
that runtime service invocations from an atomic context (i.e., EFI pstore)
cannot block.
So use a semaphore instead, and use down_trylock() in the nonblocking case.
We don't use a mutex here because the mutex_trylock() function must not
be called from interrupt context, whereas the down_trylock() can.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sylvain Chouleur <sylvain.chouleur@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
All efivars operations are protected by a spinlock which prevents
interruptions and preemption. This is too restricted, we just need a
lock preventing concurrency.
The idea is to use a semaphore of count 1 and to have two ways of
locking, depending on the context:
- In interrupt context, we call down_trylock(), if it fails we return
an error
- In normal context, we call down_interruptible()
We don't use a mutex here because the mutex_trylock() function must not
be called from interrupt context, whereas the down_trylock() can.
Signed-off-by: Sylvain Chouleur <sylvain.chouleur@intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sylvain Chouleur <sylvain.chouleur@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
This patch replaces the spinlock in the efivars struct with a single lock
for the whole vars.c file. The goal of this lock is to protect concurrent
calls to efi variable services, registering and unregistering. This allows
us to register new efivars operations without having in-progress call.
Signed-off-by: Sylvain Chouleur <sylvain.chouleur@intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sylvain Chouleur <sylvain.chouleur@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
ESRT support is built by default for all architectures that define
CONFIG_EFI. However, this support was not wired up yet for ARM/arm64,
since efi_esrt_init() was never called. So add the missing call.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
On ARM and arm64, ioremap() and memremap() are not interchangeable like
on x86, and the use of ioremap() on ordinary RAM is typically flagged
as an error if the memory region being mapped is also covered by the
linear mapping, since that would lead to aliases with conflicting
cacheability attributes.
Since what we are dealing with is not an I/O region with side effects,
using ioremap() here is arguably incorrect anyway, so let's replace
it with memremap() instead.
Acked-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
efi_mem_reserve() allows us to permanently mark EFI boot services
regions as reserved, which means we no longer need to copy the image
data out and into a separate buffer.
Leaving the data in the original boot services region has the added
benefit that BGRT images can now be passed across kexec reboot.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Peter Jones <pjones@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Môshe van der Sterre <me@moshe.nl>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
We can use the new efi_mem_reserve() API to mark the ESRT table as
reserved forever and save ourselves the trouble of copying the data
out into a kmalloc buffer.
The added advantage is that now the ESRT driver will work across
kexec reboot.
Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Peter Jones <pjones@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
