The previous cleanup of BMC attributes left a few holes, and if
you run with lockdep debugging with a BMC with the proper attributes,
you could get a warning.
This patch removes all the unused attributes from the BMC structure,
since they are all declared in the .data section now. It makes
the attributes all static. It fixes the referencing of the
attributes in a couple of cases that dynamically added the files
depending on BMC information.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Cc: Huang Ying <ying.huang@intel.com>
Tested-by: Alexei Starovoitov <ast@plumgrid.com>
The sunxi factor clocks usage was changed in
clk: sunxi: Give sunxi_factors_register a registers parameter
However the sun9i core clocks were not fixed up in that patch,
resulting in breakage. This patch fixes that.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Before this commit sunxi_factors_register uses of_iomap(node, 0) to get
the clk registers. The sun6i prcm has factor clocks, for which we want to
use sunxi_factors_register, but of_iomap(node, 0) does not work for the prcm
factor clocks, because the prcm uses the mfd framework, so the registers
are not part of the dt-node, instead they are added to the platform_device,
as platform_device resources.
This commit makes getting the registers the callers duty, so that
sunxi_factors_register can be used with mfd instantiated platform device too.
While at it also add error checking to the of_iomap calls.
This commit also drops the __init function from sunxi_factors_register since
platform driver probe functions are not __init.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Now that the clock driver supports PLL6 and MBUS on sun8i correctly,
add the corresponding clock nodes to the dtsi.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The clock driver has unified support for the ahb1 clock.
Unify the clock nodes so it works.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The clock driver has unified support for the ahb1 clock.
Unify the clock nodes so it works.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
This patch unifies the sun6i AHB1 clock, originally supported
with separate mux and divider clks. It also adds support for
the pre-divider on the PLL6 input, thus allowing the clock to
be muxed to PLL6 with proper clock rate calculation.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The ahb1_sdram clock gate is only used for accessing the sdram
controller's registers over the bus. It is not used for actually clock
the controller or the dram, hence it does not need to be protected.
This also gets rid of the problem when the protected ahb1_sdram gate
is prepared/enabled while it is still an orphan, and the operation
is not propagated to the correct parent.
This was confirmed on my A23 tablet and my A31 Hummingbird.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
usbphy0 support in the sunxi usb-phy driver has been merged, but the
dtsi's for sun4i/sun5i haven't been updated. This results in the phy
driver failing to load, breaking usb support.
Fixes: 6827a46f59 ('phy: sun4i: add support for USB phy0')
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The failure paths if we fail to wake the card are less than desirable,
but there's not really a graceful way to handle this case currently.
I'll keep this situation in mind when I get to fixing other vm-related
issues.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_ttm_tt_unpopulate() is supposed to return right after calling
ttm_dma_unpopulate() in the case of a coherent buffer. The return
statement was omitted, leading to the pages being unmapped twice. Fix
this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Check that length specified in a component of a symlink fits in the
input buffer we are reading. Also properly ignore component length for
component types that do not use it. Otherwise we read memory after end
of buffer for corrupted udf image.
Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
CC: stable@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Do not disable clock gate "hclk_emem_peri", otherwise EMAC clocks no longer work
and it breaks ethernet on RK3066 and RK3188. It fixes a regression introduced by
commit 78eaf6095c ("clk: rockchip: disable unused clocks").
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Fixes: 78eaf6095c ("clk: rockchip: disable unused clocks")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This patch adds CLK_IGNORE_UNUSED flag to hclk_usb_peri, hclk_usbotg0
and hclk_usbotg1 because these clocks must remain enabled to use the
USB controllers in host mode.
This fixes a regression introduced by commit 78eaf6095c
("clk: rockchip: disable unused clocks").
Signed-off-by: Julien CHAUVEAU <julien.chauveau@neo-technologies.fr>
Fixes: 78eaf6095c ("clk: rockchip: disable unused clocks")
Reviewed-by: Romain Perier <romain.perier@gmail.com>
Tested-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
It seems that ever since (536f6b9 mmc: dw_mmc: Reset DMA before
enabling IDMAC) landed upstream that SD cards have been very unhappy
on rk3288-evb. They were a little unhappy before that change, but
after that change they're REALLY unhappy.
It turns out that the above fix happens to fix a corruption when
reading card information during probe time. Without the fix we didn't
detect that high speed SD cards could actually support high speed.
With the fix we suddenly detect that they're high speed and we try to
use them at 50MHz. That doesn't work so well on EVB with the default
drive strength (maybe because there are two physical SD card slots
hooked up to the same pin?).
Fix the problem by bumping up the drive strength of the sdmmc lines.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Fixes: 536f6b91d2 ("mmc: dw_mmc: Reset DMA before enabling IDMAC")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The node field of struct cpufreq_cooling_device was reintroduced in
2dcd851fe4 (thermal: cpu_cooling: Update always cpufreq policy with
thermal constraints) but without the documentation that it once had.
Add it back so that all the fields of struct cpufreq_cooling_device
are documented.
Cc: Yadwinder Singh Brar <yadi.brar@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Enable Intel Powerclamp driver on Xeon cpu id 0x56, package C-state
is available on this CPU for idle injection.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
When amdkfd and radeon are compiled inside the kernel image (not as modules),
radeon will load before amdkfd, which will cause a bug when radeon will probe
the GPUs.
When the two drivers are compiled as modules, amdkfd is loaded after radeon is
loaded but before radeon starts probing the GPUs. This is done because radeon
loads the amdkfd module through symbol_request function.
This patch makes amdkfd load before radeon when they are both compiled inside
the kernel image, which makes the behavior similar to the case when they are
modules, and prevents the kernel bug.
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
AMD GPU devices are dependent on AMD IOMMU controller functionality to allow
the GPU to access a process's virtual memory address space, without the need
for pinning the memory.
This patch changes the order in the drivers makefile, so iommu/ subsystem is
linked before gpu/ subsystem. That way, if the gpu and iommu drivers are
compiled inside the kernel image (not as modules), the correct order of device
loading is still maintained (iommu module is loaded before gpu module).
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
All of mmc controllers include SDMMC, SDIO0, SDIO1, and EMMC on RK3288
are limited to 150Mhz. It was mainly caused by two reasons:
- RK3288's IO pad(except DDR IO pad) is generic, which can only support
the max of 150Mhz.
- Mmc controller was designed at 150Mhz, and the pressure test by IC team
was based on this freequency point.
Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
We'd like to be able to set the clock rate of the sclk_uart clocks and
actually be able to achieve clock rates greater than 24MHz. To do
this we need to be able to pass rate changes upward.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This patch enables the cpufreq-dt driver in mvebu_v7_defconfig, as it
is used on Armada XP platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
This patch enables the phy drivers for the SATA controller on Marvell's 88f6192.
Without them it is not possible to use SATA drives attached to this processor.
Signed-off-by: Evgeni Dobrev <evgeni@studio-punkt.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Iomega ix2-200 can be powered off via GPIO 0 pin 17,
this patch wires up the gpio-poweroff driver to do it.
Signed-off-by: Richard Kunze <richard.kunze@web.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
The original MTD partition layout for the Iomega ix2-200 leaves most of the
available space unused. This patch changes the layout to use all remaining
MTD space after the partitions for u-boot/u-boot-env and the kernel uimage
as a "rootfs" partition.
Signed-off-by: Richard Kunze <richard.kunze@web.de>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
The commit b4607572ef (ARM: mvebu: remove conflicting muxing on
Armada 370 DB) removes the hog pins muxing. As it is explained in the
commit log it solves a warning a boot time, but more important it also
allows using the Giga port 0 of the board.
Unfortunately in the same time the commit 4904a82a93 (arm: mvebu:
move Armada 370/XP pinctrl node definition armada-370-xp.dtsi) was
merged and it introduced again the hog pins muxing. Because of it, the
Giga port 0 of the board is no more usable.
This commit remove again the conflicting muxing (hopefully for the
last time).
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
[andrew@lunn.ch: Correct commit IDs]
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 4904a82a93 ("arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi")
I have here new device IDs and a fix for double free bug I introduced.
I also fix an issue with the RFKILL interrupt - the HW needs us to ACK
the interrupt again after we reset it.
Liad fixes an issue with the firmware debugging infrastructure.
While working on torture scenarios of firmware restarts, Eliad found an
issue which he fixed.
Pull a VDSO fix from Andy Lutomirski:
"One vdso fix for a longstanding ASLR bug that's been in the news lately.
The vdso base address has always been randomized, and I don't think there's
anything particularly wrong with the range over which it's randomized,
but the implementation seems to have been buggy since the very beginning.
This fixes the implementation to remove a large bias that caused a small
fraction of possible vdso load addresess to be vastly more likely than
the rest of the possible addresses."
Signed-off-by: Ingo Molnar <mingo@kernel.org>
