This adds ACPI support for the APM X-Gene SATA ports. When the system
boots using ACPI table, the SATA ports are able to configure using the
values supplied by the ACPI table rather than the DTS.
Signed-off-by: NFeng Kan <fkan@apm.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Commit 9013d64e ("ata: sata_mv: fix disk hotplug for Armada
370/XP SoCs") added some manipulation of the LP_PHY_CTL register, but
using magic values. This commit changes the code to use proper
definitions for the LP_PHY_CTL register, which allows to document what
the different bits are doing.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NSimon Guinot <simon.guinot@sequanux.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

486b908d (HID: wacom: do not send pen events before touch is up/forced out)
introduces a kernel oops when plugging a tablet without touch.

wacom->shared is null for these devices so this leads to a null pointer
exception.

Change the condition to make it clear that what we need is wacom->shared
not NULL.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Going over the virtio mmio code, I noticed that it doesn't correctly
access modern device config values using "natural" accessors: it uses
readb to get/set them byte by byte, while the virtio 1.0 spec explicitly states:

	4.2.2.2 Driver Requirements: MMIO Device Register Layout

	...

	The driver MUST only use 32 bit wide and aligned reads and writes to
	access the control registers described in table 4.1.
	For the device-specific configuration space, the driver MUST use
	8 bit wide accesses for 8 bit wide fields, 16 bit wide and aligned
	accesses for 16 bit wide fields and 32 bit wide and aligned accesses for
	32 and 64 bit wide fields.

Borrow code from virtio_pci_modern to do this correctly.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

drivers/regulator/tps65910-regulator.c: In function ‘tps65910_parse_dt_reg_data’:
drivers/regulator/tps65910-regulator.c:1018: error: implicit declaration of function ‘of_get_child_by_name’
drivers/regulator/tps65910-regulator.c:1018: warning: assignment makes pointer from integer without a cast
drivers/regulator/tps65910-regulator.c:1034: error: implicit declaration of function ‘of_node_put’
drivers/regulator/tps65910-regulator.c:1056: error: implicit declaration of function ‘of_property_read_u32’
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

bad argument if(tmp)... in check_free_hole

fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!

[airlied: excellent, this was my task for today].
Signed-off-by: NKrzysztof Kolasa <kkolasa@winsoft.pl>
Reviewed-by: NChris wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The linux kernel has supported the TiVo Slide remote control for some time, but
does not recognize the USB ID of the newer Slide Pro. This patch adds the
missing data structures so the newer remote will be recognized by the driver,
thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be
mapped with a hwdb file.
Signed-off-by: NForest Wilkinson <web11.forest@tibit.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

virtio_mmio currently lacks generation support which
makes multi-byte field access racy.
Fix by getting the value at offset 0xfc for version 2
devices. Nothing we can do for version 1, so return
generation id 0.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

virtio spec requires that all drivers set DRIVER_OK
before using devices. While rpmsg isn't yet
included in the virtio 1 spec, previous spec versions
also required this.

virtio rpmsg violates this rule: is calls kick
before setting DRIVER_OK.

The fix isn't trivial since simply calling virtio_device_ready earlier
would mean we might get an interrupt in parallel with adding buffers.

Instead, split kick out to prepare+notify calls.  prepare before
virtio_device_ready - when we know we won't get interrupts. notify right
afterwards.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Commit df9e26d0 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
added an "rtc_src" DT property to specify the clock used as a source to
the S3C real-time clock.

Not all SoCs needs this so commit eaf3a659 ("drivers/rtc/rtc-s3c.c:
fix initialization failure without rtc source clock") changed to check
the struct s3c_rtc_data .needs_src_clk to conditionally grab the clock.

But that commit didn't update the data for each IP version so the RTC
broke on the boards that needs a source clock. This is the case of at
least Exynos5250 and Exynos5440 which uses the s3c6410 RTC IP block.

This commit fixes the S3C rtc on the Exynos5250 Snow and Exynos5420
Peach Pit and Pi Chromebooks.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Tyler Baker <tyler.baker@linaro.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This adds a missing break statement to VFIO_DEVICE_SET_IRQS handler
without which vfio_pci_set_err_trigger() would never be called.

While we are here, add another "break" to VFIO_PCI_REQ_IRQ_INDEX case
so if we add more indexes later, we won't miss it.

Fixes: 6140a8f5 ("vfio-pci: Add device request interface")
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>

This reverts commit e4df3a0b
("i2c: core: Dispose OF IRQ mapping at client removal time")

Calling irq_dispose_mapping() will destroy the mapping and disassociate
the IRQ from the IRQ chip to which it belongs. Keeping it is OK, because
existent mappings are reused properly.

Also, this commit breaks drivers using devm* for IRQ management on
OF-based systems because devm* cleanup happens in device code, after
bus's remove() method returns.
Signed-off-by: NJakub Kicinski <kubakici@wp.pl>
Reported-by: NSébastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
[wsa: updated the commit message with findings fromt the other bug report]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Fixes: e4df3a0b

Some drivers compare struct clk pointers as a means of knowing
if the two pointers reference the same clock hardware. This behavior is
dubious (drivers must not dereference struct clk), but did not cause any
regressions until the per-user struct clk patch was merged. Now the test
for matching clk's will always fail with per-user struct clk's.

clk_is_match is introduced to fix the regression and prevent drivers
from comparing the pointers manually.

Fixes: 035a61c3 ("clk: Make clk API return per-user struct clk instances")
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>
[arnd@arndb.de: Fix COMMON_CLK=N && HAS_CLK=Y config]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[sboyd@codeaurora.org: const arguments to clk_is_match() and
remove unnecessary ternary operation]
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
type T;
identifier f;
@@

static T f (...) { ... }

@@
identifier r.f;
declarer name EXPORT_SYMBOL_GPL;
@@

-EXPORT_SYMBOL_GPL(f);
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Fixes: 035a61c3 "clk: Make clk API return per-user struct clk instances"
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Starting with commit b4b55cda
("x86/PCI: Refine the way to release PCI IRQ resources")

the device lost its irq resource on module unload. While that's ok and
apparently intentional, the driver never got the resource back on module load

The code apparently wants drivers to disable the pci device at pci device
driver removal, so lets do that. That fixes the issue.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

cppcheck on lines 917 and 977 show an ineffective assignment
to the dma buffer pointer:

[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]:
[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]:
  (warning) Assignment of function parameter has no effect
  outside the function. Did you forget dereferencing it?

On a successful DMA buffer lookup, the dma buffer pointer is
assigned, however, on failure it currently is left in an
undefined state.

The original intention in the error exit path was to nullify
the pointer on an error (which the original code failed to
do properly). This patch fixes this also ensures all failure
paths nullify the buffer pointer on the error return.

Fortunately the callers to vmw_translate_mob_ptr and
vmw_translate_guest_ptr are checking on a return status and not
on the dma buffer pointer, so the original code worked.
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NColin Ian King <colin.king@canonical.com>

To take down the MOB and GMR memory types, the driver may have to issue
fence objects and thus make sure that the fence manager is taken down
after those memory types.
Reorder device init accordingly.

Cc: <stable@vger.kernel.org>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Experimental lockdep annotation added to the TTM lock has unveiled a
couple of lock dependency violations in the vmwgfx driver. In both
cases it turns out that the device_private::reservation_sem is not
needed so the offending code is moved out of that lock.

Cc: <stable@vger.kernel.org>
Acked-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

This device disconnects every 60s without X
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses by disabling memory and/or I/O decoding
and subsequently causing (CPU side) accesses to the respective address
ranges, which (depending on system configuration) may be fatal to the
host.

Note that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.

This is CVE-2015-2150 / XSA-120.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

Just keep it working, seems to fix some PLL problems.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.

This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@ubuntu.com>
Reported-by: NJon Arne Jørgensen <jonjon.arnearne@gmail.com>
Reported-and-tested-by: NGustaw Smolarczyk <wielkiegie@gmail.com>
Cc: stable@vger.kernel.org (v3.18+)
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add testcase variants with '/' in the options string to test for
scan beyond end path name terminated by ':'.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NRob Herring <robh@kernel.org>

Ensure proper handling of paths with appended options (after ':'),
where those options may contain a '/'.

Fixes: 7914a7c5 ("of: support passing console options with stdout-path")
Reported-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NLeif Lindholm <leif.lindholm@linaro.org>
Cc: <stable@vger.kernel.org> # 3.19
Signed-off-by: NRob Herring <robh@kernel.org>

This patch fix the wrong expected value of of_property_match_string
in of_selftest_property_string.
Signed-off-by: NWang Long <long.wanglong@huawei.com>
Signed-off-by: NRob Herring <robh@kernel.org>

Remove the duplicate of_changeset_init. In of_selftest_changeset
testcase, the "struct of_changeset chgset" is initialized twice,
but only once is enough. so, drop the first initializtion code.
Signed-off-by: NWang Long <long.wanglong@huawei.com>
Signed-off-by: NRob Herring <robh@kernel.org>

The unittest fails to link if I2C or I2C_MUX is a loadable module:

  drivers/built-in.o: In function `selftest_i2c_mux_remove':
  unittest.c:(.text+0xb0ce4): undefined reference to `i2c_del_mux_adapter'

This changes the newly added IS_ENABLED() checks to use IS_BUILTIN()
instead, which evaluates to false if the other driver is a module.
Reported-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: d5e75500 ("of: unitest: Add I2C overlay unit tests.")
Signed-off-by: NRob Herring <robh@kernel.org>

Commit 3e7f7626 ("of/overlay: Do not generate duplicate nodes") removed
the only use of the 'grandchild' variable, which leads to the following build
warning:

drivers/of/overlay.c: In function 'of_overlay_apply_single_device_node':
drivers/of/overlay.c:89:31: warning: unused variable 'grandchild' [-Wunused-variable]
  struct device_node *tchild, *grandchild;
                               ^

Remove this unused variable.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRob Herring <robh@kernel.org>

Support for devicetree serial consoles via 'stdout-path' causes
bootconsoles to be disabled when the vt dummy console loads, since
there is no preferred console (the preferred console is not added
until the device is probed).

Ensure there is at least a preferred console, even if never matched.

Requires: "console: Fix console name size mismatch"
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NRob Herring <robh@kernel.org>

Long ago I found that I was getting sporadic errors when booting SNB,
with the symptom being that the first batch died with IPEHR != *ACTHD,
typically caused by the TLB being invalid. These magically disappeared
if I held the forcewake during the entire ring initialisation sequence.
(It can probably be shortened to a short critical section, but the whole
initialisation is full of register writes and so we would be taking and
releasing forcewake almost continually, and so holding it over the
entire sequence will probably be a net win!)

Note some of the kernels I encounted the issue already had the deferred
forcewake release, so it is still relevant.

I know that there have been a few other reports with similar failure
conditions on SNB, I think such as
References: https://bugs.freedesktop.org/show_bug.cgi?id=80913

v2: Wrap i915_gem_init_hw() with its own security blanket as we take
that path following resume and reset.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

commit 05a2fb15 ("drm/i915: Consolidate forcewake code")
failed to take into account that we have used to reset both
the gen6 style and the multithreaded style forcewake registers.
This is due to fact that ivb can use either, depending on how the
bios has set up the machine.

Mimic the old semantics before we have determined the correct variety
and reset both before the ecobus probe.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This fixes a regression from

commit 5ed0bdf2
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Jul 16 21:05:06 2014 +0000

    drm: i915: Use nsec based interfaces

that made a negative timeout return immediately rather than the
previously defined behaviour of waiting indefinitely.

Testcase: igt/gem_wait
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89494Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: stable@vger.kernel.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: fixed a checkpatch complaint about whitespace.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The kernel in_irq() function tests for hard-IRQ context only, so if a
system is run with the kernel 'threadirqs' option selected, the test in
intel_check_page_flip() generates lots of warnings, because then it gets
called in soft-IRQ context.

We can instead use in_interrupt() which allows for either type of
interrupt, while still detecting and complaining about misuse of the
page flip code if it is ever called from non-interrupt context.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

With drm-next, we can get a backtrace from sleeping
with mutex detection.

this is due to the callback checking the txmsg state taking
the mutex, which can cause a sleep inside a sleep,

Daniel went over it and was happy we could drop this mutex
in this case.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The internal framebuffers we create to remap legacy cursor ioctls to
plane operations for the universal plane support shouldn't be linke to
the file like normal userspace framebuffers. This bug goes back to the
original universal cursor plane support introduced in

commit 161d0dc1
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Jun 10 08:28:10 2014 -0700

    drm: Support legacy cursor ioctls via universal planes when possible (v4)

The isn't too disastrous since fbs are small, we only create one when the
cursor bo gets changed and ultimately they'll be reaped when the window
server restarts.

Conceptually we'd want to just pass NULL for file_priv when creating it,
but the driver needs the file to lookup the underlying buffer object for
cursor id. Instead let's move the file_priv linking out of
add_framebuffer_internal() into the addfb ioctl implementation, which is
the only place it is needed. And also rename the function for a more
accurate since it only creates the fb, but doesn't add it anywhere.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick)
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

virtio balloon has this code:
        wait_event_interruptible(vb->config_change,
                                 (diff = towards_target(vb)) != 0
                                 || vb->need_stats_update
                                 || kthread_should_stop()
                                 || freezing(current));

Which is a problem because towards_target() call might block after
wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing
the task_struct::state collision typical of nesting of sleeping
primitives

See also http://lwn.net/Articles/628628/ or Thomas's
bug report
http://article.gmane.org/gmane.linux.kernel.virtualization/24846
for a fuller explanation.

To fix, rewrite using wait_woken.

Cc: stable@vger.kernel.org
Reported-by: NThomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NThomas Huth <thuth@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

virtio spec requires that all drivers set DRIVER_OK
before using devices. While balloon isn't yet
included in the virtio 1 spec, previous spec versions
also required this.

virtio balloon might violate this rule: probe calls
kthread_run before setting DRIVER_OK, which might run
immediately and cause balloon to inflate/deflate.

To fix, call virtio_device_ready before running the kthread.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org

Commit 7d78cbef (serial: 8250_dw: add ability to handle
the peripheral clock) introduces handling for a second clk
to 8250_dw.c which is the driver also for LPSS UART. The
second clk forces us to provide identifier (con_id) for the
clkdev we create.

This fixes an issue where 8250_dw.c is getting the same
handler for both clocks.

Fixes: 7d78cbef (serial: 8250_dw: add ability to handle the peripheral clock)
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Similar to the reasoning for the previous commit

	DIV_ROUND_CLOSEST(parent_rate, rate)

might not be the best integer divisor to get a good approximation for
rate from parent_rate (given the metric for CLK_DIVIDER_ROUND_CLOSEST).

For example assume a parent rate of 1000 Hz and a target rate of 700.
Using DIV_ROUND_CLOSEST the suggested divisor gets calculated to 1
resulting in a target rate of 1000 with a delta of 300 to the desired
rate. With choosing 2 as divisor however the resulting rate is 500 which
is nearer to 700.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>

It's an invalid approach to assume that among two divider values
the one nearer the exact divider is the better one.

Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO
and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16
are the candidates to choose from yielding rates 125 Hz and 62.5 Hz
respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still
the better divider as 62.5 is nearer to 89 than 125 is.

Fixes: 774b5143 (clk: divider: Add round to closest divider)
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>