summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2016-05-31drm/omap: include linux/seq_file.h where neededArnd Bergmann
The omapdrm driver relies on this header to be included implicitly, but this does not always work, and I get this error in randconfig builds: gpu/drm/omapdrm/dss/hdmi_phy.c: In function 'hdmi_phy_dump': gpu/drm/omapdrm/dss/hdmi_phy.c:34:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] gpu/drm/omapdrm/dss/hdmi_wp.c: In function 'hdmi_wp_dump': gpu/drm/omapdrm/dss/hdmi_wp.c:26:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] gpu/drm/omapdrm/dss/hdmi_pll.c: In function 'hdmi_pll_dump': gpu/drm/omapdrm/dss/hdmi_pll.c:30:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] This adds the #include statements in all files that have a seq_printf statement. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-05-31Revert "drm/omap: no need to select OMAP2_DSS"Peter Ujfalusi
This reverts commit 1c278e5e3718d15475ec08ee2135f37a6b13361c. If DRM_OMAP does not select OMAP2_DSS it is possible to build a kernel with DRM_OMAP only and not selecting OMAP2_DSS. Since omapdrm depends on OMAP2_DSS this will result on broken kernel build. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-05-31drm/omap: Remove regulator API abusePeter Ujfalusi
regulator_can_change_voltage() is deprecated and it's use is not necessary as commit: 6a0028b3dd67b regulator: Deprecate regulator_can_change_voltage() describers it clearly. Also, regulator_set_voltage() is misused in the driver, as it is supposed to be used only in cases where the regulator voltage needs to be changed dynamically at runtime. In DSS's case, we always want a fixed voltage, set in the .dts files. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-05-31OMAPDSS: HDMI5: Change DDC timingsJim Lodes
The DDC scl high and low times were set to the minimum values from the i2c specification, but the i2c specification takes into account the rise time and fall time to calculate the frequency. To pass HDMI certification DDC can not exceed 100kHz therefore in a system where the rise times and fall times are negligible the high and low times for scl need to be 10us. Signed-off-by: Jim Lodes <jim.lodes@garmin.com> Signed-off-by: J.D. Schroeder <jay.schroeder@garmin.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-05-31OMAPDSS: HDMI5: Fix AVI infoframeJim Lodes
The AVI infoframe R0-R3 in the 2nd data byte represents the Active Format Aspect Ratio. It is four bits long not two bits. This fixes that mask used to extract the bits before writing the bits to the hardware registers. Signed-off-by: Jim Lodes <jim.lodes@garmin.com> Signed-off-by: J.D. Schroeder <jay.schroeder@garmin.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-05-31drm/omap: fix OMAP4 hdmi_core_powerdown_disable()Tomi Valkeinen
hdmi_core_powerdown_disable() is supposed to disable HDMI core's power-down mode. However, the function sets the power-down bit to 0, which means "enable power-down". This hasn't caused any issues as the PD seems to affect only interrupts from HDMI core, and none of those interrupts are used at the moment. CEC functionality requires core interrupts, and the PD mode needs to be fixed. This patch fixes hdmi_core_powerdown_disable() to actually disable the PD mode. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
2016-05-31drm/omap: Fix missing includesTomi Valkeinen
With certain kernel config options many omapdrm files fail to compile due to missing include of linux/gpio/consumer.h and linux/of.h. This patch adds those includes. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Dan Murphy <dmurphy@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2016-05-31drm/omapdrm: include pinctrl/consumer.h where neededArnd Bergmann
In some configurations, we can build the OMAP dss driver without implictly including the pinctrl consumer definitions, causing a build error: gpu/drm/omapdrm/dss/dss.c: In function 'dss_runtime_suspend': gpu/drm/omapdrm/dss/dss.c:1268:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration] This adds an explicit #include. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-05-30Merge branch 'linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes the following issues: - missing selection in public_key that may result in a build failure - Potential crash in error path in omap-sham - ccp AES XTS bug that affects requests larger than 4096" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: ccp - Fix AES XTS error for request sizes above 4096 crypto: public_key: select CRYPTO_AKCIPHER crypto: omap-sham - potential Oops on error in probe
2016-05-30gpio: drop lock before reading GPIO directionLinus Walleij
When adding the gpiochip, the GPIO HW drivers' callback get_direction() could get called in atomic context. Some of the GPIO HW drivers may sleep when accessing the register. Move the lock before initializing the descriptors. Reported-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-05-30gpio: bail out silently on NULL descriptorsLinus Walleij
In fdeb8e1547cb9dd39d5d7223b33f3565cf86c28e ("gpio: reflect base and ngpio into gpio_device") assumed that GPIO descriptors are either valid or error pointers, but gpiod_get_[index_]optional() actually return NULL descriptors and then all subsequent calls should just bail out. Cc: stable@vger.kernel.org Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Andrew Lunn <andrew@lunn.ch> Fixes: fdeb8e1547cb ("gpio: reflect base and ngpio into gpio_device") Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-05-30gpio: handle compatible ioctl() pointersLinus Walleij
If we're using the compatible ioctl() we need to handle the argument pointer in a special way or there will be trouble. Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs") Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-05-30vfio/type1: Fix build warningAlex Williamson
This function cannot actually be called with npage = 0, so in practice this doesn't return an uninitialized value. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-05-30vfio/pci: Fix ordering of eventfd vs virqfd shutdownAlex Williamson
Both the INTx and MSI/X disable paths do an eventfd_ctx_put() for the trigger eventfd before calling vfio_virqfd_disable() any potential mask and unmask eventfds. This opens a use-after-free race where an inopportune irqfd can reference the freed signalling eventfd. Reorder to avoid this possibility. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-05-30cpufreq: intel_pstate: Downgrade print level for _PPCSrinivas Pandruvada
Downgrade pr_info to pr_debug for the "_PPC limits will be enforced" message. In server systems with many cores this message is annoying. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-30phy: exynos-mipi-video: avoid uninitialized variable useArnd Bergmann
A rework of the exynos-mipi-video driver caused a warning about the new __set_phy_state function potentially accessing a variable before its initialization: drivers/phy/phy-exynos-mipi-video.c: In function '__set_phy_state': drivers/phy/phy-exynos-mipi-video.c:238:13: error: 'val' may be used uninitialized in this function [-Werror=maybe-uninitialized] return val & data->resetn_val; ~~~~^~~~~~~~~~~~~~~~~~ drivers/phy/phy-exynos-mipi-video.c:235:6: note: 'val' was declared here u32 val; The failure scenario here is the offset passed into a the stub regmap_read() function that does not modify its output, however regmap_read() can also fail for other reasons, so adding error handling (in this case, returning zero from is_running) seems the best solution. Note that this warning showed up with the ARM s5pv210_defconfig, indicating that we most likely want to either enable CONFIG_REGMAP in that defconfig as well, or disable the phy-exynos-mipi-video driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 97a3042f7616 ("phy: exynos-mipi-video: Rewrite handling of phy registers") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2016-05-30ACPI / Thermal / video: fix max_level incorrect valueAaron Lu
commit 059500940def (ACPI/video: export acpi_video_get_levels) mistakenly dropped the correct value of max_level and that caused the set_level function following failed and the acpi_video backlight interface didn't get created. Fix this by passing back the correct max_level value. While at it, also fix the param used in acpi_video_device_lcd_query_levels where acpi_handle is expected but acpi_video_device is passed. Fixes: 059500940def (ACPI/video: export acpi_video_get_levels) Reported-and-tested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-30pinctrl: nomadik: fix inversion of gpio directionLinus Walleij
The input/output directions were inversed on the GPIO direction read function. Loose a ! and it is correct. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-05-30gpio: flush direction status in gpiochip_lock_as_irq()Linus Walleij
As irqchip and gpiochip functions are orthogonal, the IRQ set-up or something else can have changed the direction of the GPIO line from what the GPIO descriptor knows when we get into gpiochip_lock_as_irq(). Make sure to re-read the direction setting if we have the .get_direction() callback enabled for the chip. Else we get problems like this: iio iio:device2: interrupts on the rising edge gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ genirq: Failed to request resources for l3g4200d-trigger (irq 111) on irqchip nmk1-32-63 iio iio:device2: failed to request trigger IRQ. st-gyro-i2c: probe of 2-0068 failed with error -22 Fixes: 72d320006177 ("gpio: set up initial state from .get_direction()") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-05-30gpio: lpc32xx: disable broken to_irq supportSylvain Lemieux
The "to_irq" functionality is broken inside this driver since commit 76ba59f8366f ("genirq: Add irq_domain-aware core IRQ handler"). The addition of the new lpc32xx irqchip driver in 4.7, fixed the lpc32xx platform interrupt issue. When switching to the new lpc32xx irqchip driver, a warning appear in the lpc32xx gpio driver: warning: "NR_IRQS" redefined. To remove this warning (temporary solution), this patch disables the broken "to_irq" mapping functionality support. Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-05-30clk: rockchip: fix cpuclk registration error handlingXing Zheng
It maybe due to a copy-paste error the error handing should be cclk not clk when checking if the cpuclk registration succeeded. Reported-by: Lin Huang <lin.huang@rock-chips.com> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2016-05-30clk: rockchip: Revert "clk: rockchip: reset init state before mmc card ↵Douglas Anderson
initialization" This reverts commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization"). Though not totally obvious from the commit message nor from the source code, that commit appears to be trying to reset the "_drv" MMC clocks to 90 degrees (note that the "_sample" MMC clocks have a shift of 0 so are not touched). The major problem here is that it doesn't properly reset things. The phase is a two bit field and the commit only touches one of the two bits. Thus the commit had the following affect: - phase 0 => phase 90 - phase 90 => phase 90 - phase 180 => phase 270 - phase 270 => phase 270 Things get even weirder if you happen to have a bootloader that was actually using delay elements (should be no reason to, but you never know), since those are additional bits that weren't touched by the original patch. This is unlikely to be what we actually want. Checking on rk3288-veyron devices, I can see that the bootloader leaves these clocks as: - emmc: phase 180 - sdmmc: phase 90 - sdio0: phase 90 Thus on rk3288-veyron devices the commit we're reverting had the effect of changing the eMMC clock to phase 270. This probably explains the scattered reports I've heard of eMMC devices not working on some veyron devices when using the upstream kernel. The original commit was presumably made because previously the kernel didn't touch the "_drv" phase at all and relied on whatever value was there when the kernel started. If someone was using a bootloader that touched the "_drv" phase then, indeed, we should have code in the kernel to fix that. ...and also, to get ideal timings, we should also have the kernel change the phase depending on the speed mode. In fact, that's the subject of a recent patch I posted at <https://patchwork.kernel.org/patch/9075141/>. Ideally, we should take both the patch posted to dw_mmc and this revert. Since those will likely go through different trees, here I describe behavior with the combos: 1. Just this revert: likely will fix rk3288-veyron eMMC on some devices + other cases; might break someone with a strange bootloader that sets the phase to 0 or one that uses delay elements (pretty unpredicable what would happen in that case). 2. Just dw_mmc patch: fixes everyone. Effectly the dw_mmc patch will totally override the broken patch and fix everything. 3. Both patches: fixes everyone. Once dw_mmc is initting properly then any defaults from the clock code doesn't mattery. Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> [emmc and sdmmc still work on all current boards in mainline after this revert, so they should take precedence over any out-of-tree board that will hopefully again get fixed with the better upcoming dw_mmc change.] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2016-05-30clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_srcXing Zheng
There was a typo, swapping 'c' <--> 'g'. Signed-off-by: Xing Zheng <zhengxing@rock-chips.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2016-05-30clk: rockchip: mark rk3399 GIC clocks as criticalBrian Norris
We never want to kill the GIC. Noticed when making other clock fixups, and seeing the newly-constructed clock tree try to disable cpll, where we had this parent structure: aclk_gic <------\ |--- aclk_gic_pre <-- cpll <-- pll_cpll aclk_gic_noc <--/ Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2016-05-30clk: rockchip: initialize flags of clk_init_data in mmc-phase clockHeiko Stuebner
The flags element of clk_init_data was never initialized for mmc- phase-clocks resulting in the element containing a random value and thus possibly enabling unwanted clock flags. Fixes: 89bf26cbc1a0 ("clk: rockchip: Add support for the mmc clock phases using the framework") Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2016-05-30drm/imx: plane: Don't set plane->crtc in ipu_plane_update()Liu Ying
Since the drm core sets plane->crtc correctly, we don't need to do that. Signed-off-by: Liu Ying <gnuiyl@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm/imx: ipuv3-plane: Constify ipu_plane_funcsLiu Ying
Signed-off-by: Liu Ying <gnuiyl@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm/imx: imx-ldb: honor 'native-mode' property when selecting video mode from DTLothar Waßmann
This patch allows to select a specific video mode from a list of modes defined in DT by setting the 'native-mode' property appropriately. This change does not affect the behaviour of existing platforms, since they either: - have just one display-timings subnode - have the native-mode property pointing to the first entry - let the bootloader select the appropriate timing Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm/imx: parallel-display: remove dead codeLothar Waßmann
The 'mode_valid' flag is never set in this driver. Remove it and the code that depends on it. Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm/imx: use bus_flags for pixel clock polarityPhilipp Zabel
This patch allows panels to set pixel clock and data enable pin polarity other than the default of driving data at the falling pixel clock edge and active high display enable. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm/imx: ipuv3-plane: enable UYVY and VYUY formatsPhilipp Zabel
Advertise the DRM_FORMAT_UYVY and DRM_FORMAT_VYUY formats to userspace. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm/imx: parallel-display: use of_graph_get_endpoint_by_regs helperPhilipp Zabel
Instead of using of_graph_get_port_by_id() to get the port and then of_get_child_by_name() to get the first endpoint, get to the endpoint in a single step. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm/imx: imx-ldb: use of_graph_get_endpoint_by_regs helperPhilipp Zabel
Instead of using of_graph_get_port_by_id() to get the port and then of_get_child_by_name() to get the first endpoint, get to the endpoint in a single step. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm/imx: imx-ldb: Add DDC supportSteve Longerbeam
Add support for reading EDID over Display Data Channel. If no DDC adapter is available, falls back to hardcoded EDID or display-timings node as before. Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-30drm: sun4i: do cleanup if RGB output init failsChen-Yu Tsai
sun4i_rgb_init() can fail, which results in TCON failing to bind. In this case we need to do cleanup, specificly unregistering the dotclock, which is regmap based, and the regmap is registered as part of the sun4i_tcon_bind(). Failing to do so results in a NULL pointer reference when the CCF tries to turn off unused clocks. Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm/sun4i: Convert to connector register helpersMaxime Ripard
Now that connector register helpers have been created, switch to them. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm/sun4i: remove simplefb at probeMaxime Ripard
If simplefb was setup by our bootloader and enabled in the DT, we will have a first framebuffer loaded in our system. However, as soon as our DRM driver will load, it will reset the controller, initialise it and, if the framebuffer emulation is enabled, register a second framebuffer device. This is obviously pretty bad, since the first framebuffer will be some kind of a black hole, with memory still reserved that we can write to safely, but not displayed anywhere. Make sure we remove that framebuffer when we probe so we don't end up in that situation. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm/sun4i: rgb: panel is an error pointerMaxime Ripard
In case of an error, our pointer to the drm_panel structure attached to our encoder will hold an error pointer, not a NULL pointer. Make sure we check the right thing. Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output") Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm/sun4i: defer only if we didn't find our panelMaxime Ripard
Our code currently defers our probe on any error, even if we were not expecting to have one at all. Make sure we return -EPROBE_DEFER only when we were supposed to have a panel, but it's not probed yet. Also fix a typo while we're at it. Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output") Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm/sun4i: rgb: Validate the clock rateMaxime Ripard
Our pixel clock cannot reach a high enough rate for some rather high while common resolutions (like 1080p60). Make sure we filter the resolutions we cannot reach in our mode_valid function. Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output") Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm/sun4i: request exact rates to our parentsMaxime Ripard
Our pixel clock currently only tries to deal with the current parent rate. While that works when the resolution is the same than the one already program, or when we can compute directly the rate from the current parent rate, it cannot work in most situation when we want to change the frequency, and we end up with an improper pixel clock rate, which obviously doesn't work as expected. Ask our parent for all the possible dividers if it can reach that frequency, and return the best parent rate to the clock framework so that we can use it. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm: sun4i: fix probe error handlingArnd Bergmann
gcc points out a possible uninitialized variable use in sun4i_dclk_create(): drivers/gpu/drm/sun4i/sun4i_dotclock.c: In function 'sun4i_dclk_create': drivers/gpu/drm/sun4i/sun4i_dotclock.c:139:12: error: 'clk_name' may be used uninitialized in this function [-Werror=maybe-uninitialized] init.name = clk_name; The warning only shows up when CONFIG_OF is disabled, and the property is never filled, but the same bug can show up even when CONFIG_OF is enabled but of_property_read_string_index returns another error. To fix it, this ensures that sun4i_dclk_create propagates any error from of_property_read_string_index. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm: sun4i: print DMA address correctlyArnd Bergmann
The newly added sun4i drm driver prints a dma address using the %x format string, which cannot work when dma_addr_t is 64 bit, and gcc warns about this configuration: drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_update_layer_buffer': drm/sun4i/sun4i_backend.c:193:84: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=] DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr); drm/sun4i/sun4i_backend.c:201:84: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=] DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr); This changes the code to use the explicit %pad format string, which always prints the right length. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30drm/sun4i: add COMMON_CLK dependencyArnd Bergmann
The sun4i drm driver uses the clk-provider interfaces, which are not available when CONFIG_COMMON_CLK is disabled: drivers/gpu/drm/sun4i/sun4i_dotclock.c:19:16: error: field 'hw' has incomplete type struct clk_hw hw; In file included from ../include/asm-generic/bug.h:13:0, from ../arch/arm/include/asm/bug.h:59, from ../include/linux/bug.h:4, from ../include/linux/io.h:23, from ../include/linux/clk-provider.h:14, from ../drivers/gpu/drm/sun4i/sun4i_dotclock.c:13: drivers/gpu/drm/sun4i/sun4i_dotclock.c: In function 'hw_to_dclk': include/linux/kernel.h:831:48: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] ... This adds a Kconfig dependency to prevent the driver from being enabled in this case. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-29sfc: use flow dissector helpers for aRFSEdward Cree
Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-29net: nps_enet: Disable interrupts before napi rescheduleElad Kanfi
Since NAPI works by shutting down event interrupts when theres work and turning them on when theres none, the net driver must make sure that interrupts are disabled when it reschedules polling. By calling napi_reschedule, the driver switches to polling mode, therefor there should be no interrupt interference. Any received packets will be handled in nps_enet_poll by polling the HW indication of received packet until all packets are handled. Signed-off-by: Elad Kanfi <eladkan@mellanox.com> Acked-by: Noam Camus <noamca@mellanox.com> Tested-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-29ptp: oops in ptp_ioctl()Dan Carpenter
If we pass ERR_PTR(-EFAULT) to kfree() then it's going to oops. Fixes: 2ece068e1b1d ('ptp: use memdup_user().') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-30dmaengine: at_xdmac: double FIFO flush needed to compute residueLudovic Desroches
Due to the way CUBC register is updated, a double flush is needed to compute an accurate residue. First flush aim is to get data from the DMA FIFO and second one ensures that we won't report data which are not in memory. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Cc: stable@vger.kernel.org #v4.1 and later Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-05-30dmaengine: at_xdmac: fix residue corruptionLudovic Desroches
An unexpected value of CUBC can lead to a corrupted residue. A more complex sequence is needed to detect an inaccurate value for NCA or CUBC. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Cc: stable@vger.kernel.org #v4.1 and later Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-05-30dmaengine: at_xdmac: align descriptors on 64 bitsLudovic Desroches
Having descriptors aligned on 64 bits allows update CNDA and CUBC in an atomic way. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Cc: stable@vger.kernel.org #v4.1 and later Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
generated by cgit (git 2.34.1) at 2025-09-15 09:32:33 +0000